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SECTION  1.  GENERAL 


1.1  Purpose  of  the  Subsystem  Specification.  The  Subsystem  Specification  for  the  wing 
sites  of  the  Air  Force  Integrated  Readiness  Measurement  System  (AFIRMS),^  Contract  No 


F49642-83-C-0022),  is  written  to  fulfill  the  following  objectives: 


'  ~_a»  To  provide  a  detailed  definition  of  the  wing  subsystem  functions. 

•  b.  ;  To  communicate  specification  details  of  the  subsystem  functional  requirements 

c*.  To  define,  in  detail,  the  interfaces  with  other  systems  and  subsystems  and  the 
facilities  to  be  utilized  for  accomplishing  these  interfaces. 

The  subsystem  specification  also  contains,  as  appendices,  the  specifications  for  each 
of  the  products  required  for  subsystem  implementation. 


This  subsystem  specification  generally  applies  to  tactical  fighter  wings,  and  only 
broadly  relates  to  other  types  of  wings.  Requirements  for  various  wing  types  are 
thoroughly  specified  during  the  in-depth  analysis  that  precedes  implementation  at  those 
wings. 


1.2  Introduction  to  AFIRMS.  This  section  provides  a  brief  introduction  to  AFIRMS.  A 
more  complete  description  is  provided  in  the  AFIRMS  Functional  Description. 


1.2.1  AFIRMS  Synopsis. 


1.2.1. 1  Key  AFIRMS  Concepts.  AFIRMS  is  an  automated,  tasking  based,  capability 
assessment  system.  As  such,  AFIRMS  evaluates  unit  and  force  capability  to  perform 
tasked  missions  based  on  the  availability  of  specific  resources. 


The  conceptual  requirements  for  AFIRMS  are  two-fold: 

(1)  Assessment  of  combat  capability  against  specific  tasking.  The  user  can 
assess  unit/force  combat  capability  against  any  planned  or  ad  hoc  tasking, 
e.g.,  War  Mobilization  Plan  (WMP),  Operation  Plan  (OPlan),  Fragmentary 
Order,  Air  Tasking  Order  (ATO),  Contingency  Plan,  etc. 
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(2)  Assessment  of  combat  capability  based  on  budget  appropriations. 

AFIRMS  provides  a  tool  for  computing  long-term  readiness  and 
sustainability  trends,  spanning  two  to  six  fiscal  years.  This  tool  permits 
comparison  of  readiness  and  sustainability  by  fiscal  year  and  can 
therefore  highlight  the  impact  of  appropriation  changes.  Thus,  changes  in 
funding  are  related  to  changes  in  force  readiness  and  sustainability.  Also, 
senior  Air  Force  decision  makers  are  supported  during  budget 
deliberations  and  Air  Force  budget  allocations. 

b.  AFIRMS  implementation  has  two  key  concepts: 

(1)  Integrated  approach  to  tasking  based  capability  assessments.  AFIRMS  has 
two  integrative  dimensions.  First,  all  applicable  resources  and  their  usage 
interactions  are  considered.  For  example,  in  sortie  capability  assessment, 
AFIRMS  evaluates  capability  in  terms  of  all  four  essential  resource  types 
(aircrew,  aircraft,  munitions,  fuel),  their  interdependencies,  and  their 
generative  components  (such  as  spares  for  aircraft,  training  qualifications 
for  aircrew,  load  crews  for  munitions,  and  hot  pits  for  fuel).  Second, 
other  automated  systems  (such  as  the  Combat  Supplies  Management 
System  (CSMS),  Combat  Fuels  Management  System  (CFMS),  Weapon 
System  Management  Information  System  (WSMIS),  etc.)  outputs  are 
integrated  into  capability  assessment  calculations  through  system 
interfaces  between  those  systems  and  AFIRMS. 

(2)  Data  Quality  Assurance.  Capability  assessment  is  no  better  than  the  data 
upon  which  it  is  based.  Therefore,  AFIRMS  emphasizes  a  user  orientation 
toward  quality  assurance  of  source  data.  Unit  and  other  data  input  level 
users  are  provided  effective  tools  to  accomplish  their  daily  activities  and 
therefore  develop  a  vested  interest  in  AFIRMS  data  currency  and 
validity.  Capability  assessment  data  can  then  be  extracted  for  use  by 
higher  or  parallel  users  with  maximum  confidence  in  its  validity. 


1.2. 1.2  AFIRMS  Functions.  Four  basic  AFIRMS  functions  combine  to  assess  readiness 
capability: 


a.  Translate  Tasking.  As  a  tasking  based  capability  assessment  system,  tasking 
must  be  converted  into  a  standard  format  recognized  by  AFIRMS.  Tasking  is 
defined  in  AFIRMS  to  the  unit  level  and  may  consist  of  actual,  hypothetical, 
standard,  or  contingency  tasking.  Any  of  these  taskings  can  be  defined  within 
specified  WM-P  or  OPlan  constraints,  at  the  option  of  the  user.  Likewise,  the 
tasking  may  be  defined  by  the  user  for  present,  historic  or  future  requirements. 

b.  Define  Resources.  The  resource  definition  function  of  AFIRMS  ensures  that 
information  about  inventory  status  is  available  and  accurate.  Wherever 
possible,  this  data  is  obtained  by  interface  with  other  functional  systems.  As 
with  tasking,  resource  information  can  be  defined  for  actual,  hypothetical, 
standard,  or  contingency  situations,  either  present,  historic,  or  future. 
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Ci  Determine  Ability  to  Perform.  Determining  the  force's  ability  to 
perform  is  the  essential  function  of  AFIRMS.  The  tasking  and 
resource  data  are  processed  to  determine  how  much  of  the  specified 
tasking  can  be  accomplished  with  the  resources  available.  Ability  to 
perform  is  evaluated  in  terms  of  the  task  metric  ( sorties ,  etc . )  and 
the  cost  metric  (dollars)  to  provide  readiness/sustainability  and 
dollars  to  readiness  assessments. 

d.  Aggregate.  Analyze  and  Present  Data.  Aggregation,  analysis  and 
presentation  ensure  the  proper  grouping  and  display  of  data  to 
provide  useful  information  at  the  unit,  major  command  and  HQ  USAF. 
Aggregation  refers  to  the  creation  of  a  composite  understanding  of 
capability  for  several  units. 

1.2.2  AFIRMS  Documentation.  A  set  of  nine  types  of  documents  describes 
AFIRMS.  A  list  of  these  AFIRMS  documents  is  provided  below  along  with  a  short 
description  of  the  particular  aspects  of  AFIRMS  which  are  addressed  by  each 
document. 


Functional  Description  (FD) .  The  FD  provides  the  description  of 
AFIRMS  concepts  in  user  terms.  It  is  the  baseline  document  which 
ties  the  AFIRMS  documents  together. 

Economic  Analysis  (EA).  The  EA  states  AFIRMS  estimated  costs.  It 
explains  the  cost  factors  of  AFIRMS  implementation  alternatives  and 
states  the  recommended  alternative. 

Management  Plan.  The  Management  Plan  provides  the  top-level, 
integrative  frame  of  reference  for  the  AFIRMS  Program.  The  plan 
focuses  on  the  processes  which  provide  technical  and  administrative 
control  of  AFIRMS.  Key  annexes  to  the  Management  Plan  are  the 
Evolutionary  Implementation  Plan,  the  Configuration  Management 
Support  Plan,  and  the  Systems  Interface  Support  Plan. 

System  Specification.  The  AFIRMS  System  Specification  adds  the 
design  requirements  to  the  functional  concepts  in  the  FD.  It  divides 
the  system  into  subsystems  (HQ  USAF,  HQ  USAFE  (MAJCOM),  and  Wing 
(unit))  and  assigns  functions  required  within  each  subsystem.  The 
system  specification  details  the  overall  architecture,  intersite 
interface  gateways,  processing  logic  flows  and  the  communications 
network  specifications. 

Subsystem  Specifications.  There  are  three  AFIRMS  subsystem 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
the  Wing  (unit/ squadron) .  Subsystem  specifications  detail  the 
specific  design  and/or  performance  requirements  of  the  system  at  that 
level.  Design  details  cover  the  architecture,  required  functions, 
the  functional  users,  intrasite  interface  gateways,  and  applicable 
processing  logic  flows. 
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f.  Database  Specifications.  There  are  three  AFIRMS  database 

specifications:  HQ  USAF,  HQ  USAFE  (MAJCQM/numbered  Air  Force),  and 
Wing  ( unit/squadron ) .  These  specifications  describe  the  database 
architecture,  size  and  content,  as  well  as  logical  data  relationships 
for  the  functions  performed  at  each  of  the  AFIRMS  levels. 
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Data  Requirements  Document  (DRD).  The  DRD  identifies,  categorizes,  and 
groups  the  generic  types  of  data  used  in  AFIRMS.  It  also  defines  each  type  of 
AFIRMS  data  element  (attribute  class). 


h.  Product  Descriptions  (PDs).  The  PDs  visually  portray  the  products  which 
implement  the  AFIRMS  functions  as  input  and  output  tools. 

i.  Transform  and  Model  Descriptions.  The  Transform  and  Model  Descriptions 
Document  defines  how  AFIRMS  calculates  the  output  data  from  the  input  data. 
Specific  algorithmic  calculations  are  provided.  Logical  groups  of  algorithms 
forming  AFIRMS  models  and  transforms  are  described. 


1.3  Project  References.  Accurate  assessment  of  force  readiness  and  sustainability  has 
been  a  constant  concern  of  Air  Force  commanders  and  their  staffs.  This  concern  has  been 
supported  by  an  intensified  DoD-wide  interest  in  capability.  In  response  to  this  Air  Force 
concern,  the  Directorate  of  Operations  and  Readiness  initiated  the  AFIRMS  Program. 
AFIRMS  has  been  under  development  through  a  learning  prototype  and  is  designed  to 
provide  Air  Force  commanders  with  a  complete,  timely,  and  accurate  assessment  of  their 
operational  readiness  and  sustainability.  In  performing  this  function,  AFIRMS  provides 
combat  capability  assessments  to  Air  Force  leaders  at  HQ  USAF,  major  command 
(MAJCOM),  and  wing  levels  of  command  to  aid  them  in  making  total  force  readiness 
decisions.  AFIRMS  also  supports  day-to-day  operations  and  crisis  management  as  well  as 
planning  and  programming  activities  at  all  command  levels. 

The  Program  Management  Office  (PMO)  responsible  for  contract  management  of  the 
AFIRMS  Learning  Prototype  Phase  (LPP)  and  this  document  is  the  Data  Systems  Design 
Office  (DSDO/XO),  Gunter  Air  Force  Station  (AFS),  Alabama;  the  Office  of  Primary 
Responsibility  (OPR)  is  the  United  States  Air  Force  Readiness  Assessment  Group 
(AF/XOOIM).  Three  operational  centers  have  been  in  use  as  LPP  testbed  sites:  The 
Pentagon,  Washington,  D.C.;  HQ  USAFE,  Ramstein  Air  Base  (AB),  Germany;  and  the  52nd 
Tactical  Fighter  Wing  (TFW),  Spangdahlem  AB,  Germany. 

References  which  are  applicable  to  the  history  and  development  of  the  AFIRMS 
Program  are  listed  below  along  with  references  concerning  programming  and 
documentation  standards. 


a.  AFIRMS  Data  Requirements  Document,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

b.  AFIRMS  Economic  Analysis,  Final,  SofTech,  Contract  No.  F49642-83-C-0022, 
31  May  1985.  (Unclassified) 
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AFIRMS  Evolutionary  Implementation  Plan,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Functional  Description,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAF  Database  Specification,  Final,  SofTech,  Contract  No. 

F 49642-83-C-002  2,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAF  Subsystem  Specification,  Final,  SofTech,  Contract  No. 

F 49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAFE  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  HQ  USAFE  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Product  Descriptions,  Final,  SofTech,  Contract  No.  F49642-83-C-0022 
31  May  1985.  (Unclassified) 

AFIRMS  System  Specification,  Final,  SofTech,  Contract  No.  F49642-83-C-0022 
31  May  1985.  (Unclassified) 

AFIRMS  Transform  and  Model  Descriptions,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Wing  Database  Specification,  Final,  SofTech,  Contract  No. 

F 4964 2-83-C-0022,  31  May  1985.  (Unclassified) 

AFIRMS  Wing  Subsystem  Specification,  Final,  SofTech,  Contract  No. 

F 49642-83-C-0022,  31  May  1985.  (Unclassified) 

System  Interface  Design  for  the  AFIRMS  LPP  and  the  Combat  Fuels 
Management  System  (CFMS),  SofTech,  Contract  No.  F49642-83-C-0022, 

28  February  1985.  (Unclassified) 

System  Interface  Design  for  the  AFIRMS  LPP  and  the  Air  Force  Operations 
Resource  Management  System  (AFORMS),  SofTech,  Contract  No. 
F49642-83-C-0022,  2  November  1984.  (Unclassified) 

AFR  700-2,  Information  Systems  Planning,  26  October  1984.  (Unclassified) 

AFR  700-5,  Information  System  Requirements  Board,  9  November  1984. 
(Unclassified) 

AFR  205-16,  Automated  Data  Processing  (ADP)  Security  Policy,  Procedures, 
and  Responsibilities,  1  August  1984.  (Unclassified) 

AFR  300-4,  Vol.  4,  Air  Force  Data  Dictionary,  1  May  1984.  (FOUO) 

DoD-STD-7935. 1,  Automated  Data  Systems  (ADS)  Documentation  Standards, 

24  April  1984.  (Unclassified) 


u.  JCS  Pub  1,  Department  of  Defense  Dictionary  of  Military  and 
Associated  Terms,  24  April  1984.  (Unclassified) 

v.  AFR  700-1,  Managing  Air  Force  Information  Systems,  2  March  1984. 
(Unclassified) 

w.  AFIRMS  LPP  ADP  Security  Plan,  SofTech,  Contract  No.  F49642-83-C-0022, 
13  February  1985.  (FOUO) 

x.  AFR  300-4,  Vol.  3,  Air  Force  Data  Dictionary,  15  August  1983.  (FOUO) 

y.  Sustainability  Assessment  Model  (formerly  CAC)  Functional 
Description,  Contract  No.  F33700-83-G-002005701,  8  April  1983. 
(Unclassified) 

z.  AFR  700-3,  Information  Systems  Requirements  Processing, 

30  November  1984.  (Unclassified) 

aa.  MIL-STD-480  Configuration  Control-Engineering  Changes,  Deviations, 
and  Waivers. 

bb.  MIL-STD-483  Configuration  Management  Practices  for  Systems, 

Equipment,  Munitions,  and  Computer  Programs. 

cc.  USAF  Operational  Major  Command  Functional  Area  Requirement  (FAR), 
SofTech,  Contract  No.  F49642-82-C-0045,  15  December  1982. 

(Unclassified) 

dd.  AFR  55-15,  Unit  Combat  Readiness  Reporting  (C-Ratings)  (Unit  Status 
and  Identity  Report  (UNITREP),  RCS:HAF-XOO(AR)7U2(DD)) , 

22  November  1982.  (Unclassified) 

ee.  USAFE  Annex  to  USAF  FAR,  SofTech,  Contract  No.  F49642-82-C-0045 , 

20  August  1982.  (Unclassified) 

ff.  AFIRMS  FAR,  SofTech,  Contract  No.  MDA-903-76-C-0396 ,  14  March  1980. 
(Unclassified) 

gg.  AFIRMS  Data  Analysis,  SofTech,  15  February  1979.  (Unclassified) 

hh.  User's  View  of  AFIRMS,  SofTech,  1  November  1978.  (Unclassified) 

ii.  AFR  700-9,  Information  Systems  Standards,  15  March  1985. 

(Unclassified) 

jj.  AFM  11-1,  U.S.  Air  Force  Glossary  of  Standardized  Terms,  Vol.  1, 

2  January  1976.  (Unclassified) 

*  Material  contained  in  references  cc  and  ee  expands  on  that  found  in 
reference  ff. 
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kk.  AFIRMS  Data  Automation  Requirement  (DAR)  ,  Final,  SofTech,  Contract 
No.  MDA-903-76-C-0396,  14  March  1980.  (Unclassified) 

11.  JCS  Memorandum  of  Policy  172,  1  June  1982.  (Unclassified) 

mm.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB)  1. 

nn.  FIPS  PUB  15,  Section  1. 

oo.  Military  Airlift  Command  (MAC)  AFIRMS  Requirments  Analysis,  SofTech, 
Contract  No.  F49642-83-C-0022,  30  September  1985.  (Unclassified) 

pp.  Analysis  of  Strategic  Air  Command  (SAC)  Capability  Assessment  Metrics, 
SofTech,  Contract  No.  F49642-83-C-0022,  30  September  1985. 

( Unclassified) 

qq.  Strategic  Air  Command  (SAC)  AFIRMS  Requirements  Analysis,  SofTech, 
Contract  No.  F49642-83-C-0022,  30  September  1985.  (Unclassified) 

rr.  Analysis  of  Strategic  Air  Command  (SAC)  Capability  Assessment 

Metrics,  SofTech,  Contract  No.  F49642-83-C-0022,  30  September  1985. 
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1«4  Abbreviations  and  Acronyms, 


AB 

ADP 

ADPS 

AF 

AFIRMS 

AFR 

AFS 

ANSI 

ASCII 

ATO 

ATOC 

BPI 

BPS 

CAMS 

CAS 

CBU 

CFMS 

CN 

CNM 

CONPLAN 

CONUS 

CPI 

CPL 

CPS 

CPU 


Air  Base 

Automated  Data  Processing 
Automated  Data  Processing  System 
Air  Force 

Air  Force  Integrated  Readiness  Measurement  System 
Air  Force  Regulation 
Air  Force  Station 

American  National  Standards  Institute 

American  Standard  Code  for  Information  Exchange 

Air  Tasking  Order 

Allied  Tactical  Operations  Center 

Bits  Per  Inch 

Bits  Per  Second 

Core  Automated  Maintenance  System 

Combat  Ammunition  System 

Cluster  Bomb  Unit 

Combat  Fuels  Management  System 

Central  Node 

Central  Node  Module 

Concept  Plan 

Continental  United  States 

Characters  Per  Inch 

Characters  Per  Line 


CRC 


Characters  Per  Second 
Central  Processing  Unit 
Cyclical  Redundancy  Checking 


CRT 


CSMS 

DAR 

DBMS 

DDN 

DoD 

DRD 

DSDO 

EA 

EIP 

EMSEC 

FA 

FAW 

FD 

FIPS  PUB 
FOUO 
FTP 
HOL 

HQ  USAF 

HQ  USAFE 

IAW 

I/O 

IP 

IPS 

ISO 

LED 

LPI 

LPM 
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Cathode  Ray  Tube 

Combat  Supplies  Management  System 
Data  Automation  Requirement 
Database  Management  System 
Defense  Data  Network 
Department  of  Defense 
Data  Requirements  Document 
Data  Systems  Design  Office 
Economic  Analysis 
Evolutionary  Implementation  Plan 
Emanations  Security 
Functional  Area 
Functional  Area  Workstation 
Functional  Description 

Federal  Information  Processing  Standards  Publication 

For  Official  Use  Only 

File  Transfer  Protocol 

High  Order  Language 

Headquarters,  United  States  Air  Force 

Headquarters,  United  States  Air  Forces  Europe 

In  Accordance  With 

Input/Output 

Internet  Protocol 

Inches  Per  Second 

International  Standards  Organization 
Light  Emitting  Diode 
Lines  Per  Inch 
Lines  Per  Minute 
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$3 


m 


[l* 

I 


V 

5: 

**; 


: 

«» 

■V* 


i 


a 

V 

¥ 

¥ 

M 


I 

a 


MAC 


OPlan 


SMTP 


-  Learning  Prototype  Phase 

-  Military  Airlift  Command 


MA3COM  -  Major  Command 

MICAP  -  Mission  Capable 

NATO  -  North  Atlantic  Treaty  Organization 

NBS  -  National  Bureau  of  Standards 


-  National  Security  Agency 

-  Optical  Character  Reader 

-  Operation  Plan 


OPORD  -  Operation  Order 


-  Office  of  Primary  Responsibility 
Product  Descriptions 

-  Program  Management  Office 

-  Petroleum,  Oil,  and  Lubricants 

-  Program  Objective  Memorandum 

-  Preferred  Products  List 

-  Simple  Mail  Transfer  Protocol 

-  Tactical  Air  Force 

-  Transmission  Control  Protocol 
Tactical  Fighter  Wing 


USAFE 


United  States  Air  Forces  Europe 


WWMCCS  Intercomputer  Network 


'j 


WMP 


WSMIS 


War  Mobilization  Plan 


-  Wing  Operations  Center 


Weapon  System  Management  Information  System 


WWMCCS  -  World  Wide  Military  Command  and  Control  System 
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SECTION  2.  SUMMARY  OF  REQUIREMENTS 


AFIRMS  is  a  tasking  based  capability  assessment  system  that  assesses  readiness 
and  sustainability  by  applying  specific  tasking  (identified  to  accomplish  the 
assessments  desired)  against  selected  unit  and  theatre  resources  through  the 
use  of  automated  assessment  models.  As  a  decision  support  tool,  it  provides 
Air  Force  commanders  at  all  levels  with  the  ability  to  assess  capability  to 
meet  a  specific  tasking.  The  requirement  for  AFIRMS  is  two-fold: 

a.  Assess  capability  against  any  tasking.  The  operator  of  the  system 
can  select  a  tasking  against  which  to  make  assessments,  i.e..  War 
Mobilization  Plan  (WMP),  Operations  Plan  (OPlan),  what-if  plan,  and 
Air  Tasking  Order  (ATO).  AFIRMS  then  provides  a  capability 
assessment  against  that  scenario  in  a  mission  unit  of  measure. 

b.  Correlate  dollar  costs  to  readiness  assessment  impacts  of 
appropriations  by  fiscal  year.  The  capability  metric  transformed 
from  missions  to  dollars  for  assessments  from  this  budgetary 
perspective. 

The  worldwide  operational  AFIRMS  is  a  hierarchically  structured  system 
which  can  be  visualized  as  a  pyramid  of  distinct  operational  sites.  Each 
operational  site  performs  a  set  of  functions  which  are  distinct  from,  although 
similar  to,  other  sites  and  transmits  information  logically  upward  to  a  parent 
site.  There  are  three  basic  levels  within  the  AFIRMS  pyramid,  each  level 
being  considered  as  an  AFIRMS  subsystem.  The  highest  level  subsystem,  the 
apex  of  the  pyramid,  is  the  HQ  USAF  subsystem.  The  second  level  of  the 
pyramid  consists  of  the  MAJCOM  subsystems.  Each  Major  Command  contains  at 
least  one  AFIRMS  MAJCOM  subsystem;  one  for  the  MAJCOM  HQ,  and  one  for  each 
Numbered  Air  Force  (or  Air  Logistics  Center)  in  the  MAJCOM,  as  applicable. 

The  base  of  the  pyramid  is  composed  of  a  set  of  wing  subsystems.  Each  wing 
within  a  MAJCOM  contains  an  AFIRMS  wing  subsystem  which  is  connected  to  the 
parent  MAJCOM. 

2.1  Wing  Subsystem  Description.  The  wing  sites  in  the  operational  AFIRMS  are 
the  lowest  level  entities  in  the  eventual  worldwide  AFIRMS  distributed 
network.  Wing  sites  receive  tasking  data  from  higher  command  levels  and 
communicate  readiness  and  status  data  to  the  MAJCOMs.  Each  wing  is 
subordinate  to  a  particular  MAJCOM. 
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Although  multipi  w'pes  of  wings  exist  (e.g.,  fighter,  airlift,  etc.),  they  have  common 
characteristics.  The  f-  RMS  wing  sites  provide  products  to  support  the  major  function  of 
the  wing.  In  the  case  ol  ctical  fighter  wings,  that  is  to  produce  combat  sorties. 

AFIRMS  wing  products  provide  capabiiity  assessment  insights  that  assist  in  objectively: 

a.  Evaluating  a  wing's  ability  to  accomplish  tasking  directed  by  higher  levels  of 
command. 

b.  Determining  capability  tc  venerate  sorties  in  support  of  specific  tasking. 

c.  Executing  taskings. 

d.  Identifying  and  reporting  shortfalls  related  to  tasking,  and  relating  shortfalls  to 
specific  resource  deficiencies. 

e.  Reporting  capability  up  the  chain  of  command. 

f.  Projecting  capability. 

AFIRMS  wing  products  present  a  look  at  wing  resources  from  operations, 
maintenance,  and  support  squadron  functional  areas,  and  provide  an  integrated  assessment 
of  readiness  and  sustainability  using  wing  resources.  Due  to  the  inherent  differences  in 
missions,  wing  types  vary  in  die  resource  data  they  collect  and  the  assessment  products 
they  require.  However,  products  developed  for  a  particular  wing  within  a  specific 
MAJCOM  generally  service  all  applicable  agencies  of  that  wing. 

Two  basic  types  of  data  are  processed  by  the  wing;  tasking  data  and  resource  data. 


a.  Tasking  Data.  Wing  tasking  data  consists  of  (but  is  not  limited  to):  ATOs, 
preplanned  missions,  and  immediate  requests  (i.e.,  from  Allied  Tactical 
Operations  Center  (ATOC)).  This  tasking  data  is  received  at  the  wing  via  a 
communications  link  with  the  MA3COM/ATOC,  and  processed  by  the  wing 
subsystem  against  the  TFW  squadron  resources.  Tasking  data  received 
"manually"  is  keyed  into  the  wing  subsystem  via  user  terminal. 

b.  Unit  Resource  Data.  Wing  resource  data  is  received  from  the  squadrons  by 
means  of  manual  on-line  terminal  entries  or  interfacing  with  external  systems. 
The  general  approach  is  to  extract  data  from  existing  systems  to  the  maximum 
extent  possible.  Data  unavailable  from  other  systems  is  entered  manually.  As 
data  becomes  available  from  newly  developed  systems,  a  conversion  can  be 
made  from  manual  entry  to  automated  collection  from  the  new  system.  Some 
MA3COMs  have  centralized  resource  storage  sites  for  distribution  to  the  units 
during  a  crisis.  When  these  resources  are  to  be  used  in  the  wing  assessments, 
the  MA3COM  provides  the  wing  with  the  resupply  schedule. 
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Each  CNM  is  responsible  for  updating  the  FA  databases  attached  to  it  as  required.  It 
is  also  responsible  for  transmitting  the  data  updates  made  by  one  or  more  of  its  attached 
FAs  to  all  other  CNMs  to  allow  them  to  update  their  FA  databases  as  required. 

2.1. 1.2  Functional  Areas.  Each  FA  has  an  intelligent  device  containing  its  own  database 
and  copies  of  required  software. 

The  data  resident  on  the  FA  database  consists  of  update/read  and  read  only  data 
elements.  The  specific  data  resident  is  determined  by  the  data  needed  for  a  functional 
area's  normal  uses.  See  the  Wing  Database  Specification  for  details  of  the  data 
requirements  by  functional  user.  When  an  update  is  made  at  the  FA,  the  update 
transaction  is  sent  to  the  central  node  to  allow  update  of  the  centralized  database  and  for 
synchronization  of  the  databases  of  other  FAs. 

2. 1.1.3  Communications.  A  communications  path  is  provided  for  normal  communications 
with  a  higher  level  site.  In  addition  to  this  normal  channel  which  is  shared  between  all 
CNMs,  each  CNM  has  an  alternate  temporary  path  to  the  MA3COM  site.  Since  this 
alternate  path  is  variable  in  nature,  the  software  is  capable  of  communicating  using  a 
variety  of  protocols  and  speeds. 

A  communications  path  is  provided  for  normal  communications  between  a  FA  device 
and  a  CNM.  In  addition  to  this  normal  channel,  each  FA  has  an  alternate  temporary  path 
of  communications  (i.e.,  a  dial-up  pK  ne  line).  The  MA3COM  CNM  has  the  required 
receiving  equipment  to  accept  the  alternate  path  transmission.  It  is  possible  for  the  wing 
FA  to  use  the  alternate  transmission  path  to  -Ink  directly  to  a  CNM  at  the  MAJCOM. 
Interface  specifications  for  these  alternate  FA  communications  paths,  as  well  as  the 
determination  as  to  which  FAs  require  this  wing  specific  functionality,  are  defined  during 
the  Analysis  Phase  of  each  functional  block  implementation. 


2.2  Wing  Subsystem  Functions.  Three  levels  of  functions  are  of  interest  in  this  subsystem 
specification.  They  are:  Basic  AFIRMS  Functions,  Secondary  Functions,  and  System 
Functions. 


a.  Basic  AFiRMS  Functions.  The  building  block  functions  which  are  specific  to 
AFIRMS  and  which  are  used  (in  different  forms  and  combinations)  to  support 
the  user  with  various  types  of  data/information.  The  Basic  AFIRMS  Functions 
at  the  wing  level  are: 

(1)  Translate  Tasking.  Translates  tasking  so  that  it  can  be  used  ir.  measuring 
ability  to  perform,  i.e.,  converts  tasking  to  numbers  of  mission  capable 
aircraft,  mission  ready  crews,  munitions,  Petroleum,  Oil  and  Lubricants 
(POL),  etc.  required  to  accomplish  that  tasking.  Wing  products  that  use 
this  function  include: 

(a)  Aircraft  Tasking 

(b)  Aircrew  Generation 

(c)  Flying  Schedule 

(d)  Mission  Flow 

(e)  Mission  Profile  Definition 

(f)  Munitions  Flow 

(g)  Order  Assignments 

(h)  Tasked  Missions 

(i)  Tasked  Munitions 

(j)  Tasking  Information 

(k)  War  Mobilization  Plan 

(l)  Wing  Flying  Day 

(m)  Wing  Operations  Rates 

(2)  Define  Resources.  Provides  inventory  status  and  availability  of  resources 
(such  as  fuels,  munitions,  aircraft,  and  crews)  for  use  in  capability 
assessments.  The  Define  Resources  function  will  assist  in  allocation  of 
resources  (physical  or  fiscal)  and  forecast  results  of  trial  or  final 
allocations.  Wing  products  that  use  this  function  include: 

(a)  AGE  Availability  Status 

(b)  Aircraft  Availability 

(c)  Aircraft  Status 
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(d)  Aircrew  Availability 

(e)  Aircrew  Status 

(f)  Fuels  Status 

(g)  Munitions  A  6c  D  Availability 

(h)  Munitions  Availability  Forecast 

(0  Munitions  Load  Crew  Status 

(j)  Munitions  Status 

(k)  Supply  MICAP  Status 

(l)  Wing  Resource  Summary 

(m)  Wing  Resupply  Schedule 

(3)  Determine  Ability  to  Perform.  Given  current  and  forecast  readiness 
factors,  AFIRMS  transforms  WMPs,  ATOs,  OPlans,  and  "what-if" 
exercises  into  measurable  tasking;  computes  current  readiness  to  perform 
the  task,  projects  readiness  into  the  future;  and  calculates  resources 
consumed  by  performing  the  task.  This  function  will  provide  users  with 
the  capability  to  measure  (and  aggregate)  readiness  and  sustainability  vs. 
standard  or  one-time  tasking,  and  measure  (and  aggregate)  readiness  or 
sustainability  vs.  revised  standards,  and/or  revised  standard  tasking  using 
historic  data. 


Wing  products  that  use  the  Determine  Ability  to  Perform  function  include: 

(a)  Aircraft  Capability 

(b)  Aircrew  Capability 

(c)  Base  Fuels  Capability 

(d)  Individual  Resource  Capability 

(e)  Integrated  Capability 

(f)  Munitions  Capability 

(g)  Sortie  Generation  Model 

(h)  Task  Capability 

(4)  Aggregate,  Analyze  and  Present  Data.  This  function  deals  with  the  task 
of  properly  grouping  data  to  provide  meaningful  and  useful  data.  It  also 
develops  trend  and  variance  data  to  facilitate  exception  type  reporting  on 
unusual  developments  in  day-to-day  data. 


Aggregation  refers  to  the  creation  of  a  composite  understanding  of  the 
readiness  and  sustainability  of  a  number  of  units.  Thus,  a  MA3COM  with 
many  reporting  wings,  each  with  its  own  deficiencies  and  strengths,  can 
assess  the  readiness  (and  sustainability)  of  all  units  taken  as  a  whole. 

Wing  products  that  use  the  Aggregate,  Analyze,  and  Present  Data 
function  include: 

(a)  Base  Status  Report  Generation 

(b)  Resource  Summary  Report  Generation 

(c)  Unit  Status  Report  Generation 

b.  Secondary  AFIRMS  Functions.  In  order  to  carry  out  the  Basic  AFIRMS 
Functions,  AFIRMS  must  maintain  and  verify  data.  To  help  ensure  the  accuracy 
of  the  data  and  to  take  advantage  of  its  availability,  AFIRMS  provides  a  variety 
of  associated  capabilities  which  are  not  directly  related  to  capability 
assessment.  These  functions  are  secondary  and  some  of  them  might  be 
eliminated  if  the  circumstances  in  which  AFIRMS  operates  were  to  change. 
Examples  of  these  secondary  functions  are:  display  tasking;  perform  ad  hoc 
queries;  and  display  information  on  an  evolving  schedule.  For  a  detailed  listing 
of  these  functions,  refer  to  the  AFIRMS  System  Specification. 

c.  System  Functions.  The  standard  building  block  functions  such  as  graphics  or 
data  mangement  which  might  occur  in  any  system,  and  which,  together  with 
specially  written  subfunctions,  are  used  to  support  the  Basic  and  Secondary 
AFIRMS  Functions.  For  a  detailed  listing  of  these  functions,  refer  to  the 
AFIRMS  System  Specification. 


2.2.1  Accuracy  and  Validity.  The  accuracy  of  the  AFIRMS  database  is  essential  for  the 
generation  of  accurate  measurements.  There  are  two  categories  of  accuracy  and  validity 
that  must  be  addressed.  The  first  is  related  to  electronic  manipulation,  storage,  and 
transmission  of  data  in  the  AFIRMS  system.  The  second  is  related  to  the  interface 
between  the  user  or  other  Air  Force  systems,  and  the  AFIRMS  system. 


a.  Electronic  Manipulation/Storage/Transmission. 


(1)  The  nature  of  the  m.odels/displays  created  with  AFIRMS  does  not  require 
precision  beyond  that  achievable  with  off-the-shelf  standard  micro  or 
minicomputers  that  support  hardware  or  software  floating  point 
computations. 


(2)  Errors  in  data  transmissions  will  not  exceed  1  part  in  10  .  Parity 

checking  and  cyclical  redundancy  checking  (CRC)  ensure  that  the  data 
actually  used  internal  to  the  AFIRMS  sites  has  an  error  probability  well 
below  this  figure  by  correcting  all  1-bit  errors.  (Double-bit  errors  are 
detected  but  not  corrected.) 
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b.  User  Interfaces  to  AFIRMS.  The  user  interfaces  of  interest  are  those 
interfaces  that  introduce  new  information  into  AFIRMS.  The  concern  is  that 
the  information  destined  to  enter  the  database  be  valid.  Valid  here  means  that: 

(1)  The  individual  entering  the  information  is  authorized  to  do  so  (i.e.,  only 
logistics  personnel  may  be  authorized  to  update  logistics  information, 
using  logistics  data  forms). 

(2)  The  information  is  as  "error  free  as  possible."  This  suggests  that  input 
data  must,  in  general,  be  entered  through  well-engineered  interfaces  that 
prompt  the  user  and  check  field  contents. 

(3)  Certain  information  passed  into  the  database  has  sufficient  criticality  to 
require  verification  beyond  that  identified  in  (2)  above,  prior  to  database 
updates.  This  verification  occurs  via  supervisory  review.  Under  this 
method,  the  data  is  entered  by  an  authorized  individual.  However,  the 
information  cannot  update  the  database  or  be  transmitted  to  higher 
headquarters  by  the  individual  who  entered  it  until  a  supervisor  authorizes 
the  AFIRMS  system  to  accept  the  data.  The  method  of  authorization 
might  require  that  the  supervisor  log  on  to  the  AFIRMS  system  and  enter 
an  "unlocking"  command  that  allows  the  data  to  be  entered  and  the 
database  updated.  Information  requiring  supervisory  review  is  kept 
minimal.  Specific  data  requiring  this  quality  assurance  technique  are 
identified  during  the  Analysis  Phase  of  each  functional  block 
implementation. 

c.  System  Interfaces  to  AFIRMS.  Data  obtained  by  interface  with  other  data 
systems  is  subject  to  the  same  data  accuracy  and  validity  criteria  as  for  user 
input  data. 


2.2. 1.1  Data  Accuracy.  AFIRMS  uses  five  main  approaches  to  ensure  the  accuracy  and 
currency  of  data. 


a.  Provide  benefits  to  the  organizations  which  input  readiness  data.  If  the 

organization  which  inputs  data  receives  benefits  from  the  system,  then  it  is 
motivated  to  ensure  that  data  entered  is  current  and  accurate. 


b.  Simplify  data  input  by  using  simple  devices  and  by  grouping  inputs.  For 
example,  a  bar  code  reader  is  a  candidate  device  for  entering  a  complex 
identification  number  that  might  be  subject  to  error  if  entered  via  keyboard. 


Use  automated  edit  check  as  well  as  checks  for  the  reasonableness  of  input  data 
against  stored  parametric  values.  That  is,  all  inputs  are  programmatically 
edited  to  further  ensure  the  accuracy  and  integrity  of  the  database.  The 
system  validates  length,  format,  and  legal  values  of  all  formatted  alphanumeric 
input  data. 
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d.  All  data  entry  information  is  automatically  reviewed /checked  for  consistency 
against  other  related  information. 

e.  Obtain,  edit,  and  incorporate  data  and/or  assessments  from  other  automated 
systems. 


2.2.2  Timing. 

a.  User  Response  Time.  AFIRMS  is  an  information  processing  system  which  is 
user  intensive;  that  is,  in  general,  users  enter  data  through  a  data  capture 
device  and  request  readiness  status  onto  an  output  display.  Thus,  it  is 
imperative  that  AFIRMS  response  time  to  user  requests  be  kept  minimal. 
Response  time  as  it  applies  to  user  terminals,  consists  of  two  parts;  command 
acceptance  and  command  execution. 

(1)  Command  Acceptance.  Command  acceptance  is  the  time  between  the 
user's  initiating  transmission  of  a  command  or  transaction  to  the  system 
(such  as  by  depression  of  the  ENTER  key  or  entry  of  the  last  character  of 
a  menu  response)  and  the  appearance  of  the  first  line  of  the 
acknowledgement  from  the  system  on  the  user's  terminal  that  the 
message  has  been  received  or  an  error  condition  exists.  AFIRMS,  under 
loaded  conditions  (more  than  85%  of  terminals  in  use)  supports  a  command 
acceptance  time  of  less  than  2.5  seconds  90%  of  the  time.  At  no  time 
does  command  acceptance  time  exceed  six  seconds. 

(2)  Command  Execution.  Command  execution  is  the  elapsed  time  between 
the  command  or  transaction  entry,  and  the  appearance  of  the  first  line  on 
the  user's  display  terminal  (excluding  graphics). 

(a)  For  functions  such  as  command  entry,  text  editing  or  message 
writing  applications,  the  appearance  of  a  keyed  character  on  the 
screen  is  immediate  in  the  perception  of  the  user. 

(b)  Queries.  AFIRMS  allows  for  local  (intrasite)  queries  only,  with 
response  times  as  follows: 

_1_  Simple.  Response  time  of  1  to  3  seconds. 

2  Medium.  Response  time  of  4  to  10  seconds. 

3  Complex.  Response  time  of  1 1  to  30  seconds. 

Categorization  of  specific  queries  within  these  definitions  is 
accomplished  during  the  Analysis  Phase  of  the  functional  block 
developments.  These  times  do  not  include  sortie  generation  model, 
dollars  to  readiness  model,  or  similar  model  execution  times. 
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b.  Data  Currency.  When  changes  are  made  to  data  at  the  functional  area  level, 
those  changes  are  transmitted  to  the  central  site  database.  After  the  central 
database  is  updated,  the  changes  are  subsequently  transmitted  to  other 
functional  areas  having  the  data  in  question  resident  on  their  local  database. 

The  time  that  it  takes  to  complete  the  transactions  on  the  central  database  and 
all  affected  functional  areas  designates  the  currency  of  data  at  the  site. 

(1)  Mission-Related  Data  -  Within  a  site  this  time  period  must  be  less  than 
three  minutes  for  mission-related  data  90%  of  the  time  with  the  system 
operating  in  a  normal  mode.  AFIRMS  mission-related  data  consists  of 
current  tasking  and  current  primary  resource  status  information  or  that 
data  associated  with  a  crisis  mode.  Primary  resources  are  those  resources 
directly  utilized  by  the  capability  assessment  model. 

(2)  Non-Mission-Related  Data  -  Data  currency  within  a  site  must  be  achieved 
within  one  hour  for  non-mission-related  data  90%  of  the  time  with  the 
system  operating  in  a  normal  mode.  AFIRMS  non-mission-related  data 
consists  of  that  information  relating  to  ad  hoc,  historic,  exercise,  or 
contingency  simulations  which  neither  relate  to  the  current  situation  nor 
are  designated  as  crisis  mode  items. 

c.  Data  Age.  The  maximum  time  span  allowed  for  known  data  updates  between 
wing  and  MAJCOM  sites  is  six  hours,  regardless  of  state  of  change  for  the  data. 


2.3  Flexibility.  AFIRMS  provides  an  architecture  that  matches  the  specific  requirements 
of  each  wing  to  an  AFIRMS  site  with  compatible  hardware/software  capability. 
Additionally,  it  has  the  capability  to  grow,  i.e.,  add/change  system  focus  as  time  passes. 
Capabilities  incorporated  for  adapting  the  wing  subsystem  to  changing  requirements 
include  the  following: 

a.  Configuration  of  AFIRMS  sites  from  modular  hardware  and  software 
components.  The  modular  applications  software  is  written  in  DoD  standard  host 
independent  high  order  languages  (HOL)  for  ease  of  transportability  among 
different  hardware  configurations.  Acceptable  HOLs  are  ADA,  C,  or  other 
strongly  typed  languages  which  support  modular  software  design,  readability 
and  increased  maintainability. 

b.  A  hardware/software  building  block  approach,  coupled  with  transportable 
software,  to  facilitate  expansion  of  operational  AFIRMS  in  the  future. 

c.  Utilization  of  DoD  standardized  data  communications  protocols  and  external 
user  interfaces.  AFIRMS  implements  DoD  standard  protocols  for  network  and 
distributed  system  data  communications  and  terminal  interfaces.  Utilization  of 
the  DoD  standard  protocols  provides  for  interoperability  among  differentvendor 
equipments,  existing  and  developmental  Air  Force  AutomateJ  Data  Processing 
(ADP)  systems,  and  is  in  accordance  with  Air  Force  policy  and  guidance. 


Ability  to  interface  an  AFIRMS  site  to  other  Air  Force  systems  after  the 
AFIRMS  site  has  been  designed  and  installed.  AFIRMS  software  is  structured  so 
as  to  provide  for  new  system  integration  to  the  greatest  extent  possible.  This  is 
facilitated  by  maintaining  distinct  layers  of  software,  as  in  the  International 
Standards  Organization  (ISO)  7-Iayer  Reference  Model,  and  by  the  use  of 
controlled  standardized  data  gateways  (intersite  or  intrasite  standard  data 
communications  formats). 

Ability  to  support  secondary  (or  backup)  interfaces,  by  which  an  intermediate 
AFIRMS  site  may  be  bypassed.  For  example,  the  ability  of  a  functional  area,  in 
place  or  deployed,  to  communicate  directly  with  a  MA3COM  or  the  ability  of  a 
wing,  in  place  or  deployed,  to  bypass  the  MA3COM  and  communicate  directly 
with  HQ  USAF. 
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SECTION  3.  ENVIRONMENT 


3.1  Equipment  Environment.  The  wing  site  is  configured  to  support  Wing  Headquarters 
and  the  Wing  Operations  Center  (W'OC).  In  addition,  each  squadron  affiliated  with  the 
wing  has  equipment  that  "plugs-into"  the  wing  hardware.  Equipment  is  provided  to  each 
wing  (and  all  other  AF1RMS  sites)  on  an  "as  needed"  basis.  AF1RMS  will  not  directly 
support  unit  level  automation.  It  is  the  intent  of  AFIRMS  to  use  existing  facilities  and 
equipments  wherever  possible.  However,  at  a  minimum,  each  AFIRMS  site  contains  the 
equipment  required  for  the  Central  Node  and  one  Functional  Area  workstation.  The 
Central  node  contains  the  AFIRMS  database  for  that  site  as  well  as  the  communications 
support  for  site  to  site  communications. 

AFIRMS  utilizes  standard  Air  Force  equipment  sources  such  as  the  Air  Force 
Standard  Multiuser  Small  Computer  initiative  by  the  Air  Force  Computer  Acquisition 
Center,  TEMPEST  and  Phase  IV  Program  equipment  sources.  AFIRMS  is  designed  to  allow 
for  the  integration  of  different  computers,  peripherals,  and  communications  standards 
throughout  the  system.  This  provides  for  a  faster  and  more  cost  effective  AFIRMS 
development,  and  a  higher  degree  of  operational  flexibility. 


3.1.1  Central  Node  Equipment.  Each  AFIRMS  site  contains  a  Central  Node  consisting  of 
the  following  equipment: 


a.  One  or  more  processors,  each  capable  of  handling  four  or  more  functional 
areas.  Each  processor  is  a  32-bit  machine  with  at  least  a  24-bit  address 
structure.  Each  processor  has  several  high  bandwidth  full  duplex 
communications  paths  to  the  other  processors,  if  any,  in  the  central  node.  Each 
processor  has  the  ability  to  connect  three  or  more  terminals. 

b.  One  or  more  direct  access,  high  speed  storage  devices  capable  of  containing  the 
centralized  data  base  and  capable  of  being  logically  accessed  by  multiple 
processors.  Each  high  speed  storage  device  has  at  least  one  high  bandwidth  full 
duplex  communications  path  to  each  of  the  processors  in  the  central  node. 

c.  One  direct  access,  high  speed  storage  device  capable  of  containing  all  software 
and  system  files  for  each  processor  in  the  Central  Node. 

d.  A  mass  storage  device,  i.e.  9-track  tape  or  optical  storage  device,  capable  of 
being  accessed  by  multiple  processors. 

e.  A  communications  controller  capable  of  handling  all  external  communications 
lines  and  capable  of  being  accessed  by  multiple  local  processors. 


f.  Encryption  devices  for  each  physical  line  that  may  pass  classified  data.  The 
encryption  device  is  able  to  operate  in  a  synchronous  or  asynchronous  mode  and 
to  operate  at  the  speeds  identified  in  Section  3.1.4  of  this  subsystem 
specification,  "Communications  Equipment". 

g.  Power  conditioning  and  failure  protection  mechanisms  are  required  as  stated  in 
Section  3. 1.5.2  of  this  subsystem  specification,  "Electrical  Power".  All  "wall 
power"  must  be  filtered  to  protect  equipments  against  power  surges.  Filtered 
power  is  also  required  for  system  that  process  classified  data  to  prevent  data 
emanations.  Power  failsafe  backup  provisions  are  provided  to  preserve  memory 
in  the  event  of  power  failure.  Backup  power  terminates  during  normal 
shutdown. 

h.  A  CRT  terminal  and  line  printer  for  system  maintenance  and  operator  use. 

i.  Main  Memory.  An  initial  user  memory  capacity  of  a  minimum  of  four 
megabytes  of  user  memory  is  required.  This  user  memory  is  expandable  (in 
minimum  512K  byte  increments)  up  to  at  least  10  megabytes.  All  memory 
specifications  are  made  in  8-bit  bytes.  The  physical  organization  of  the  main 
memory  is  modular  so  that  a  failure  in  one  module  (except  the  module 
containing  the  operating  system  or  similar  support  software)  does  not  deprive 
the  system  of  the  remaining  memory.  Memory  must  be  byte  addressable  and 
volatile. 

(1)  Error  Detection.  As  a  minimum,  a  memory  error  detection  and  correction 
feature  are  provided  that  detect  double  bit  errors  and  correct  all  single 
bit  errors  for  each  byte  of  memory. 

(2)  Memory  Protection.  The  capability  to  inhibit  any  attempt  by  an 
applications  program  to  write  into  or  read  from  memory  areas  not 
allocated  to  that  program  is  required. 


3.1.2  Functional  Area  Equipment.  Each  functional  area  which  needs  to  access,  enter,  or 
modify  AFIRMS  data  is  provided  with  a  functional  area  workstation  to  communicate  with 
the  Central  Node.  Each  functional  area  workstation  contains  the  following  equipment: 


a.  One  processor  capable  of  handling  one  or  more  users  depending  on  the  needs  of 
the  functional  area.  The  processor  is,  at  a  minimum,  a  16-bit  machine. 

b.  One  direct  access,  high  speed  storage  device  capable  of  containing  the  local 
database  and  the  software/system  files. 

c.  A  mass  storage  device,  e.g.  floppy  disk  drive. 

d.  A  communications  controller  capable  of  handling  all  external 
asynchronous/synchronous  communications  between  the  functional  area 
workstation  and  the  central  node. 
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Several  miscellaneous  input/output  devices.  The  number  of  each  type  of  device 
depends  on  the  requirements  of  the  functional  area,  and  is  be  determined  during 
the  Analysis  Phase  that  precedes  implementation  at  each  site. 

An  encryption  device  for  communicating  with  the  Central  Node  if  the 
workstation  is  to  handle  classified  data.  The  encryption  device  is  able  to 
operate  either  in  a  synchronous  or  asynchronous  mode  and  to  operate  at  the 
speeds  required  by  the  communications  lines. 

Power  conditioning  and  failure  protection  mechanisms  are  required.  All  "wall 
power"  must  be  filtered  to  protect  equipments  against  power  surges.  Filtered 
power  is  also  required  for  systems  that  process  classified  data  to  prevent  data 
emanations.  Power  failsafe  backup  provisions  are  provided  to  preserve  memory 
in  the  event  of  power  failure.  Backup  power  must  terminate  during  normal 
shutdown. 

Main  Memory.  An  initial  user  memory  capacity  of  a  minimum  of  two 
megabytes  of  user  memory  is  required.  This  user  memory  is  expandable  (in 
minimum  512K  byte  increments)  up  to  at  least  8  megabytes.  All  memory 
specifications  are  made  in  8-bit  bytes.  The  physical  organization  of  the  main 
memory  is  modular  so  that  a  failure  in  one  module  (except  the  module 
containing  the  operating  system)  shall  not  deprive  the  system  of  the  remaining 
memory. 

(1)  Error  Detection.  As  a  minimum,  a  memory  error  detection  and  correction 
feature  is  provided  that  detects  double  bit  errors  and  corrects  all  single 
bit  errors  for  each  byte  of  memory. 

(2)  Memory  Protection.  The  capability  to  inhibit  any  attempt  by  an 
applications  program  to  write  into  or  read  from  memory  areas  not 
allocated  to  that  program  is  required. 


3.1.3  Input/Output  Devices.  Wing  device  requirements  for  CRT  terminals,  printers,  disk 
drives  and  magnetic  tape  drives  are  determined  during  the  Analysis  Phase  of  each  block 
implementation. 

a.  CRTs  must  possess  the  following  characteristics; 

(1)  Monochrome  Terminals:  Alphanumeric  keyboard  and  video  display; 
interface  via  standard  RS-232-C  port;  ability  to  function  as  a  system 
console;  and  sound  an  audible  tone  or  "BEEP"  when  the  ASCII  "BEL" 
character  or  its  equivalent  is  received. 

(a)  Keyboards  must  possess  the  following  characteristics: 

J_  Be  capable  of  generating  the  ASCII  128-character  subset  in 
accordance  with  FIPS  PUB  1. 

2  At  a  minimum,  conform  to  the  ANSI  Standard  X4.14-1971. 
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3  Have  a  repeat  function  for  all  printable  ASCII  characters, 
cursor  controls,  and  spacing  functions. 

4  Have  separate  keys  for  carriage  return,  control,  escape,  and 
spacing  functions. 

5  Have  a  minimum  of  16  programmable  function  keys. 

6  Have  a  numeric  keypad  to  the  right  of  the  character  keys  and 
allow  numeric  entries  from  either  the  regular  character  key  or 
the  numeric  keypad. 

7  Have  at  least  four  cursor  movement  keys  separate  from 
function  keys. 

8  Have  a  detachable  keyboard. 

9  Have  a  (screen)  hardcopy  function. 

(b)  Video  Displays  must  possess  the  following  characteristics: 

^  Display  a  minimum  of  24  lines  of  132  characters  each. 

2  Characters  displayed  consist  of  the  ASCII  95-character  subset 
IAW  FIPS  PUB  15,  Section  1. 

3  If  the  dot  matrix  character  generation  technique  is  used,  the 
matrix  must  be  at  least  7x9. 

4  Full  descenders  will  be  used  on  the  lower  case  such  as  "g,  j,  p, 
q,  y"  and  appropriate  special  characters. 

5  Implement  a  visible  cursor  denoting  the  next  character 
position  in  such  a  manner  that  its  location  is  obvious  to  the 
operator  and  does  not  obscure  any  information  (excluding 
underline)  which  may  be  displayed  at  that  position. 

6  The  cursor  must  be  addressable  and  the  capability  must  be 
provided  for  the  applications  program  to  clear  the  display  and 
to  position  the  cursor  at  any  location  on  the  screen. 

7  Have  a  non-glare  viewing  surface. 

8  Provide  reverse  video,  bold,  blink,  and  underscore  capabilities 
under  application  program  control. 

9  Brightness  must  be  externally  adjustable  by  the  terminal 
operator. 

10  The  display  must  be  green  or  amber. 

1 1  Have  selectable  terminal  transmission  rates  of  300,  1200, 

2400,  4800,  and  9600  bits  per  second  (bps). 


12  Have  a  minimum  11-inch  screen  measured  diagonally. 

J_3  Have  smooth  scrolling  capability. 

14  Support  shading  and  marking  patterns  (preprogrammed  and 
programmable). 

(c)  Other  Required  CRT  Terminal  Characteristics: 

J_  Local  memory 

2  Built-in  diagnostics  and  testing 

3  TEMPEST  certified  -  for  terminals  which  display  classified 
information 

4  Screen  print  function 

(2)  Color  Graphics  Terminals  must  possess  the  following  characteristics: 

(a)  Minimum  of  16  special  function  (programmable)  keys.  Refer  to 
Table  3-1  for  some  of  the  required  function  key  features. 

(b)  10%  of  the  terminals  require  a  video  interface  board  for  use  with 
video  projectors 

(c)  Screen  definition  of  not  less  than  720x484  individually  addressable 
and  color  definable  pixels  (i.e.,  medium  resolution) 

(d)  Minimum  11"  CRT  screen 

(e)  TEMPEST  certified  -  for  terminals  which  display  classified 
information 

(f)  Support  9600  baud  rate 

(g)  Display  a  minimum  of  1 6  colors 

(h)  Screen  print  function 

b.  Printers  must  possess  the  following  characteristics; 

(1)  Letter  Quality  Printers  must: 

(a)  Print  at  least  55  characters  per  second  (CPS). 

(b)  Print  at  least  132  characters  per  line  (CPL). 

(c)  Have  a  pressure-feed  mechanism,  interchangeable  tractor  feed  and 
an  automatic  single  sheet  feeder. 

(d)  Print  the  complete  95  character  ASCII  subset  1AW  FIPS  PUB  15, 
Section  1. 
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(e)  Have  operator  selectable  print  spacing  of  10  pitch,  12  pitch,  and 
proportional  spacing. 

(f)  Accept  forms  from  4  1/2  to  at  least  14  7/S  inches  in  width. 

(g)  Print  clearly  using  up  to  3  part  paper. 

(h)  Interface  via  RS-232-C  serial  port  and  parallel  port. 

(i)  Provide  at  least  one  font  which  is  readable  by  an  optical  character 
reader  (OCR). 

(j)  Provide  clearly  marked  vertical  and  horizontal  forms  alignment  that 
indicate  the  standard  first  print  position. 

(k)  Have  operator  controls  for  power  online/offline,  advance  to  top  of 
form  and  manual  adjustment  of  vertical  and  horizontal  paper 
alignment. 

(l)  Be  TEMPEST  certified,  when  used  for  classified  information 
printout. 

(2)  Dot  Matrix  Printers  must  possess  the  following  characteristics: 

(a)  Print  at  least  200  CPS  at  132  characters  per  line  at  10  characters 
per  inch  (CPI). 

(b)  Have  dot  addressable  graphics  with  a  minimum  resolution  of  70  dots 
per  inch  vertical  and  horizontal. 

(c)  Provide  correspondence  quality  print  capability  of  at  least  40  CPS 
at  10  CPI. 

(d)  Use  an  operator  adjustable  pin  feed  tractor  for  positive  form 
registration  movement. 

(e)  Print  the  complete  95  character  ASCII  subset  IAW  FIPS  PUB  15, 
Section  1. 

(f)  Accept  forms  ranging  from  4  1/2  to  14  7/8  inches  in  width. 

(g)  Print  full  descenders  used  on  the  lower  case  characters  "g,  j,  p,  q,  y" 
and  appropriate  special  characters. 

(h)  Print  6  and  8  lines  per  inch  (LPI),  operator  selectable. 

(i)  Print  clearly  using  up  to  3  part  paper. 

(j)  Have  controls  for  power,  online/offline,  advance  to  top  of  form  and 
manual  adjustment  of  vertical  and  horizontal  paper  alignment. 

(k)  Provide  clearly  marked  vertical  and  horizontal  forms  alignment  that 
indicate  the  standard  first  print  position. 


(l)  Provide  program  control  of  line  feed  and  form  feed. 

(m)  Interface  via  RS-232-C  serial  port  and  parallel  port. 

(n)  Be  TEMPEST  certified. 

(3)  High  Speed  (Line)  Printers  must  possess  the  following  characteristics: 

(a)  Print  at  least  500  lines  per  minute  (LPM)  (at  132  CPL)  using  the 
character  set  specified  in  (b)  below. 

(b)  Print  the  complete  95  character  ASCII  subset  IAW  FIPS  PUB  15, 
Section  1. 

(c)  Support  horizontal  spacing  of  10  or  12  CPI. 

(d)  Have  vertical  spacing  of  6  or  8  LPI  switch  or  programmer  selectable. 

(e)  Print  at  least  132  characters  per  line. 

(f)  Print  clearly  using  up  to  3  part  paper. 

(g)  Have  vertical  format  control  via  programmer  or  printer. 

(h)  Be  TEMPEST  certified. 

(i)  Have  a  diagnostic  light-emitting  diode  (LED)  indicator  for  status. 

(})  Interface  via  RS-232-C  serial  port  and  parallel  port. 

(4)  Color  Graphics  Printers  must  possess  the  following  characteristics: 

(a)  Plot  the  displayed  graph  in  the  same  ratio  (horizontal  to  vertical)  as 
the  screen  display,  in  no  more  than  90  seconds. 

(b)  Provide  minimum  resolution  of  100x85  horizontal  to  vertical  dots 
per  inch. 

(c)  Print  at  least  eight  colors. 

(d)  Print  on  bond  paper  and  transparency  (developing  of  transparency 
not  acceptable). 

(e)  Interface  via  RS-232-C  serial  port  or  parallel  port. 

(f)  Accept  a  minimum  paper  size  of  8.5x1 1  inches. 

Floppy/Microfloppy  Disk  Drives  must  possess  the  following  characteristics: 

(1)  Minimum  of  two  read/write  heads  to  provide  access  to  double-sided  disks. 

(2)  Provide  a  formatted  storage  capacity  for  one  diskette  of  at  least  1.5 
megabytes. 


(3)  Use,  at  a  minimum,  a  5.25  inch  double  sided/double  density  diskette  for 
floppy  disk  drives  and  3.5  inch  diskette  for  microfloppy  disk  drives. 


(4)  Be  compatible  with  FA  workstation  hardware  selection, 
d.  Magnetic  Tape  Drives  must  possess  the  following  characteristics: 

(1)  Be  nine  (9)  track. 

(2)  Support  a  10.5  inch  reel  of  .5  inch  by  2400  foot  standard  reel  tape. 

(3)  Support  speed  read/ write  operations  at  a  minimum  of  75  inches  per  second 
(IPS),  streaming  at  a  minimum  of  200  IPS. 

(4)  Perform  error  checking  on  all  read  operations. 

(5)  Perform  a  read  after  write  with  error  checking  on  all  write  operations. 

(6)  Have  write  protection  and  beginning  and  end  of  tape  sensor. 

(7)  Support  a  minimum  of  dual-density  (1600/6250  bits  per  inch  (BPI))  tape 
read  and  write  capability. 


3.1.4  Communications  Equipment.  Communications  equipment  is  provided  to  supply  both 
a  primary  and  a  secondary  secure  communications  path  to  all  higher  level  sites. 
Requirements  for  specific  types  and  quantities  of  communications  hardware  are 
determined  during  the  analysis  phase  that  precedes  implementation  of  each  functional 
block  at  each  site. 


3. 1.4.1  Primary  Intrasite  Communications.  Primary  communications  equipment  between 
central  nodes  and  functional  area  workstations  provides  the  following  capabilities: 

a. 

b. 

c. 

d. 

SOFT® 


Encryption  of  classified  data  transmitted  to  and  from  a  functional  area. 

A  transmission  rate  of  9600  baud  and  greater. 

A  24  hour  a  day  dedicated  line  from  the  central  node  to  each  functional  area 
workstation. 

Q 

Conditioning  to  a  bit  error  rate  of  1  in  10  . 
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3. 1.4.2  Secondary  Intrasite  Communications.  Secondary  communications  equipment 
provides  the  following  capabilities: 


a.  Encryption  of  data  transmitted  between  sites  and  classified  data  transmitted 
between  a  functional  area  and  its  central  node. 

b.  A  transmission  rate  of  300  baud  and  greater,  using  either  asynchronous  or 
synchronous  equipment. 

c.  Multiple  physical  paths  for  a  single  logical  path  (i.e.  rerouting). 

d.  Availability,  as  required,  in  the  event  primary  communications  fail.  Over  a 
given  24-hour  period,  secondary  media  are  accessible  at  least  80%  of  the  time. 


3. 1.4.3  Communications  Hardware. 


a.  Modems: 

(1)  Limited  Distance  Modems.  Limited  distance  modems  are  required  for 
on-base  use.  The  modems  must  be  capable  of  operating  over  available 
non-conditioned  voice  grade  telephone  lines  at  distances  of  at  least  6 
miles.  The  following  characteristics  are  required: 

(a)  Switchable  and  capable  of  transmitting  and  receiving  data  at  rates 
of  300,  600,  1200,  2400,  4800,  and  9600  bits  per  second  (BPS)  up  to  6 
miles. 

(b)  The  limited  distance  modem  shall  meet  EIA  Standard 
EIA-RS-232-C/CCITT  Recommendation  V.24  for  interfacing  with 
external  equipment. 

(2)  Long  Distance  Modems.  Modems  used  outside  the  United  States  (Europe, 
Asia)  on  non-conditioned  commercial  telephone  lines.  The  modem  is  a 
CODEX/V.29  data  modem  model  21962  and  must  be  homologated  (PTT 
option)  to  the  country  where  the  system  is  installed.  The  CODEX 
Universal  PTT  option,  Product  code  22120,  is  provided  when  required. 

b.  Line  Drivers.  Line  drivers  are  required  to  boost  the  electronic  signal  for 
communications  between  modems  and  CRTs  over  long  distances  (i.e.,  75  feet  or 
more). 

c.  Encryption  Devices.  NSA-endorsed  Data  Encryption  Standard  (DES)  devices  are 
required.  Functionality  may  be  combined  for  encryption  devices  and 
long/limited  distance  modems. 


3.1.5  Environmental  and  Physical  Facilities.  AFIRMS  equipment  must  operate  throughout 
the  ranges  of  electrical  power  and  environmental  tolerances  stated  below. 
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a.  Site  Locations.  Systems  are  installed  at  various  Air  Force  installations  in 
Europe.  The  central  node  location  space  ranges  from  a  minimum  of  20  square 
feet  for  the  smallest  configuration,  to  a  maximum  of  200  square  feet  for  the 
largest  configuration. 

b.  Flooring.  Equipment  shall  not  require  raised  flooring.  The  flooring  may  be 
carpeted.  There  will  be  no  special  static  control  facilities. 

c.  Ceiling  Height.  The  distance  from  the  floor  surface  to  the  u.  obstructed  ceiling 
is  at  least  8  feet. 

d.  Access  Route.  Equipment  is  installed  in  buildings  with  access  being  the  size  of 
a  normal  office  doorway.  Additionally,  some  equipment  is  installed  in  facilities 
with  vault  doors,  raised  thresholds,  and  access  by  stairways.  Some  facilities  are 
established  computer  facilities  with  a  double  door  access  route. 


3. 1.5.2  Electrical  Power.  All  equipments  must  be  capable  of  operating  within  the 
requirements  of  MIL-E-4158  and  are  further  defined  by  the  following: 


a.  Voltage  regulation  steady  state 

b.  Voltage  disturbances 
Momentary  undervoltage 
Transient  overvoltage 
Surges 

c.  Voltage  harmonic  distortion 

d.  Frequency  variation 

e.  Frequency  variation  rate  of  change 

f.  Power  factor 


+  10%  to  -15% 

30%  for  less  than  0.5  seconds 
-100%  acceptable  to  20  milliseconds 
200%  for  less  than  20  milliseconds 
1AW  IEEE  587-1980 
+3%  -5%  (with  linear  load) 

50/60Hz  plus  or  minus  1Hz 
I  Hz/second 


0.8 

g.  220/240  Volts  +or-10%,  single  phase,  2  wire. 

h.  105/110  Volts  +or-10%,  single  phase,  2  wire. 


In  addition  to  the  requirements  outlined  in  (1)  through  (8)  above,  it  is  desirable  that 
deployable  equipments  operate  using  an  Air  Force  25KVA  generator  and  that  they  be 
ruggedized  for  handling,  ground  transportation,  and  air  transport  in  accordance  with  the 
requirements  of  MIL-STD-810.  An  electrical  power  fault  detection  device  is  provided  to 
prevent  equipment  failure  (e.g.,  disk  head  crash). 
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3. 1,5,3  Air  Conditioning.  The  ambient  temperature  will  be  maintained  between  60  and  90 
degrees  Fahrenheit  with  a  relative  humidity  of  between  20  and  90  percent, 
non-condensing.  No  special  dust,  static  electricity  control,  or  chilled  water  facilities  are 
available.  The  computer  is  integrated  with  the  air  conditioning  system  to  provide 
automatic  thermal  shutdown  to  prevent  equipment  failure  during  extreme  high  or  low 
temperature  conditions. 


3. 1.5,4  Remote  Locations.  Remote  equipment  is  installed  in  various  office  environments 
within  U.S.  Air  Force  organizations.  Terminals,  office  printers,  and  modems  shall  fit  on 
normal  table  tops  or  desk  surfaces. 


3. 1.5.5  TEMPEST  Requirement.  All  equipments,  connectors,  and  cabling  that  convey 
classified  information  must  meet  the  limits  specified  in  NACSIM  5 100 A.  All  equipment 
must  be  on  the  Preferred  Products  List  (PPL)  or  approved  by  AFCSC/EPV  San  Antonio, 
TX  78243. 


3.2  Support  Software  Environment.  AFlRMS  software  is  broken  up  into  two  general 
categories:  Applications  Software  and  Support  Software.  Applications  Software  is  that 
software  which  applies  specified  algorithms  to  a  given  data  set,  and/or 
stores/retrieves/formats/analyzes/displays  a  given  set  of  data.  Applications  software 
programs/algorithms  are  enumerated  and  defined  in  the  AFlRMS  Transforms  and  Models 
Document.  This  paragraph  describes  the  support  software  which  interfaces  with  the  wing 
subsystem  applications  software  to  create  the  environment  necessary  to  support  AFlRMS' 
general  functionality  and  the  AFlRMS  Applications  Software. 


3.2.1  Central  Node  Support  Software.  Each  AFlRMS  Central  Node  requires  the  support 


software  identified  in  this  section. 
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3.2.1. 1  Operating  System.  A  general  purpose  operating  system  provides  file  access, 
program  control,  and  data  communications  interfaces.  Operating  system  operation  (e.g., 
device  I/O)  must  not  significantly  impact  the  timing  and  flexibility  of  AFIRMS  operational 
software.  The  operating  system  must  be  able  to: 

a.  Concurrently  process  a  combination  of  interactive  and  local  batch  processing. 

b.  Support  a  multi-programming  environment. 

c.  Support  both  file  and  record  level  locking  protection  capabilities. 

d.  Provide  control  over  all  hardware  and  software. 

e.  Support  logical  as  well  as  physical  mode  access  to  ail  system  peripheral  devices 
including  terminals. 

f.  Be  capable  of  detecting  and  marking  bad  blocks  while  formatting  system  and 
data  disks  as  well  as  during  normal  operation. 

g.  Support  up  to  8  concurrent  interactive  users  in  a  minimum  configuration  and  up 
to  20  concurrent  interactive  users  in  a  maximum  configuration. 

h.  Provide  access  to  a  calendar  clock  which  provides  the  calendar  date  and  time 
with  a  resolution  of  one  microsecond  (for  purposes  of  statistical  performance 
analysis  data  collection)  showing  hours,  minutes,  and  seconds  for  time;  and  day, 
month,  and  year  for  date.  This  calendar  clock  is  accessible  to  all  programming 
languages. 

i.  Detect  and  terminate  attempts  to  read  or  write  outside  of  any  programs 
allocated  memory  and  detect  and  terminate  attempts  by  any  applications 
program  to  execute  privileged  and  undefined  instructions. 

j.  Provide  high  order  language  (HOL)  runtime  support  for  input/output  (I/O), 
scheduling,  and  interprocess  communication  and  coordination. 

k.  Provide  memory  fault  detection  and  recovery  capabilities. 

l.  Support  high  level  control  of  interrupt  detection,  definition,  and  processing 
activities. 

m.  Provide  the  capability  to  perform  dynamic  load  analysis  and  reporting. 

n.  Provide  host  language  interfaces  (system  directives)  to  system  functions. 

3.2. 1.2  Utility  Routines.  The  following  utility  routines  are  required: 

a.  File  Management  System 

b.  Sort  and  Merge  Utility 
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c. 


Translation  Utility  (character  code  conversion,  e.g.  ASCII  to  EBCDIC  and 
vice-versa) 


d.  Save  and  Restore  Utility  (to  and  from  tape) 

e.  Security  Utility  (Error  surveillance  and  alerts;  to  recognize,  record  and  indicate 
misuse,  and  attempted  misuse,  of  the  system.) 

f.  Logging/Accounting  Utility  (An  automated  audit  trail  will  show:  access  made 
to  files;  how,  and  from  where  the  access  was  initiated;  the  identity  of  the 
person  or  process  that  initiated  the  access;  and  all  unauthorized  attempts.) 

g.  Diagnostic  Software 

h.  Mail  Utility 


3.2. 1.3  Communications  Software.  The  specific  requirements  for  communications 
software  are  determined  during  the  Analysis  Phase  that  precedes  implementation  at  each 
site.  However,  at  a  minimum,  a  host  interface  to  the  Defense  Data  Network  (DDN)  is 
required  for  each  AFIRMS  site.  This  interface  implements  the  full  DDN  protocol  suite, 
and  supports  site-to-site  communications  over  the  DDN.  It  also  provides  the  standard 
DDN  services  of  terminal-to-host  communications,  file  transfer,  and  electronic  mail  to 
users  of  the  AFIRMS  system.  Connection  to  the  DDN  is  via  the  ARPANET  network 
access  protocols  or  X.25.  Host-to-host  communication  shall  be  via  the  Transmission 
Control  Protocol  (TCP),  MIL-STD  1778,  and  Internet  Protocol  (IP),  MIL-STD  1777.  The 
services  which  are  supported  are  TELNET,  File  Transfer  Protocol  (FTP),  and  the  Simple 
Mail  Transfer  Protocol  (SMTP). 

Encryption  services  provided  by  the  DDN  are  limited  to  SECRET  security 
classifications.  However,  with  user  acquisition  of  TOP  SECRET  security  classification 
encryption  devices,  the  DDN  can  be  accessed  for  transmission  of  TOP  SECRET 
information. 


m 


.*• 


3.2. 1.4  Database  Management  System  (DBMS).  The  AFIRMS  DBMS  performs  the  action 
of  retrieving  a  record  from  a  file,  writing  a  record  to  a  file,  and  deleting  and  creating 
records  in  a  file.  The  DBMS  also  performs  functions  such  as  opening  and  closing  the 
database,  transaction  flow,  handling  of  the  DBMS  command  language  requests,  transaction 
parsing,  and  automatic  editing  on  input.  In  addition,  the  DBMS  allows  for  host  language 
interfaces;  save  and  restoration  of  full  or  partial  database  images;  restart  and  recovery 
capability  with  multi-user  and  multi-thread  concurrency  controls;  and  some  level  of 
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distributed  or  decentralized  data  management  with  the  appropriate  synchronization  and 
concurrency  controls.  The  specific  level  of  data  synchronization  control  and  data 
distribution  or  decentralization  required  is  determined  during  the  Analysis  Phase  that 
precedes  implementation  of  each  functional  block  for  each  MA3COM. 

For  a  detailed  statement  of  required  AFIRMS  DBMS  capabilities,  refer  to  the 
AFIRMS  TFW  Database  Specification. 

In  addition  to  the  software  that  comprises  the  AFIRMS  DBMS,  a  software  package 
provides  a  shell  to  the  DBMS  which  accomplishes  the  following: 

a.  Controls  entry  to  and  exit  from  DBMS  functions. 

b.  Provides  a  link  or  connection  between  the  communications  software  and  the  DBMS. 

c.  Controls  data  retrieval  and  data  update  transactions. 

d.  Generates  a  queue  for  transactions  by  transaction  priority. 

e.  Performs  update  notifications  to  other  sites  for  data  changes  (deletions,  additions 
or  modifications)  in  a  DBMS  file. 

f.  Determines  whether  data  retrieval  and  update  transactions  are  to  be  routed  to  the 
local  (functional  area)  database  or  the  central  database. 

g.  Provides  a  link  between  parameter  screen  software  and  the  DBMS  in  order  to 
verify  the  validity  of  parameter  selections. 


3.2.2  Functional  Area  Support  Software.  Each  AFIRMS  functional  area  requires  the 
support  software  specified  in  this  section. 


3.2.2. 1  Operating  System.  Functional  Area  operating  system  capabilities  are  identical  to 
those  of  the  Central  Node  Module,  identified  in  Section  3. 2. 1.1  of  this  subsystem 
specification.  However,  the  following  exception  applies: 


a.  The  FA  operating  system  must  support  at  least  one  interactive  user  in  a 

minimum  configuration  and  up  to  3  concurrent  interactive  users  in  a  maximum 
configuration. 
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3. 2. 2.2  Utility  Routines.  FA  utility  routine  requirements  are  the  same  as  those  of  the 
CNM,  identified  in  Section  3.2. 1.2  of  this  subsystem  specification. 


3.2.2.3  Communications  Software.  The  specific  requirements  for  communications 
software  are  determined  during  the  Analysis  Phase  that  precedes  implementation  at  each 
site.  Communications  between  the  CNM  and  the  intelligent  FA  terminals  is 
accommodated  by  communications  protocol(s)  identified  or  confirmed  during  the  Analysis 
Phase  of  each  functional  block  implementation.  The  volume  and  frequency  of  the  various 
information  gateways  by  functional  area  is  presented  in  the  AFIRMS  TFW  Database 
Specification  and  Section  4.3.2  of  this  subsystem  specification. 


3.2.2.4  Database  Management  System  (DBMS).  Functional  Area  DBMS  and  DBMS  support 
capabilities  are  identical  to  those  of  the  Central  Node  Module,  identified  in  Section 
3.2.2. 1  of  this  subsystem  specification. 

3.2.2.5  Display/Graphics  Software.  AFIRMS  display  screens  are  categorized  by  their 
method  of  display;  graphic,  tabular,  integrated  graphic  and  tabular.  The  tabular  screens 
display  the  data  values  listed  in  table  format,  i.e.,  rows  and  columns.  The  tabular  screens 
may  use  color  to  identify  data  of  like  types  to  help  the  user  assimilate  the  information. 
The  tabular  screens  also  use  colors  to  highlight  a  line  and/or  field  as  a  screen  place 
marker  for  the  user,  or  to  call  attention  to  changes  in  data  currency. 

The  graphic  screens  are  of  three  types:  bar  graph,  line  graph,  and  pictorial  (i.e., 
maps).  These  are  output  screens  only  (i.e.,  they  cannot  be  updated  through  the  display 
screen).  In  addition,  the  bar  graph  screens  have  a  data  value  atop  each  graphed  bar  that 
quantifies  the  analog  display. 

The  display  screen  generation  software  uses  standard  routines  to  generate  these 
screens.  In  summary,  the  generalized  routines  and  particular  features  are: 

a.  Tabular  Screen  Generator  must  possess  the  following  characteristics: 


(1)  Right-justified  numeric  data. 

(2)  Left-justified  alphanumeric  data. 


(3)  Line  highlighter  that  can  be  turned  (i.e.,  toggled)  on  or  off. 

(4)  Field  highlighter  that  can  be  turned  (i.e.,  toggled)  on  or  off. 

(5)  Full  screen  editor  (for  extensive  data  input  and  editing  capability) 

(6)  Linkable  to  a  special  area  on  the  screen  to  display  remarks  for  a  row  of 
data  (e.g.,  Unit  and  Base  Status  products).  This  requires  that  the  display 
routine  know  where  the  cursor  is  by  page  and  by  row  in  order  to  call  up 
the  correct  set  of  remarks/data. 

(7)  Variable  legend,  either  data-driven  or  user-defined. 

(8)  Blanking  of  repeating  column  data  (selectable). 

(9)  Capability  to  identify  (e.g.,  via  blinking,  changed  color,  etc.)  a  row  or 
column  of  data  that  has  changed  from  an  original  or  previous  data  set. 
The  means  by  which  this  "data  change  indicator"  is  activated  is 
determined  during  the  Analysis  Phase  that  precedes  implementation  of 
particular  functions  which  require  this  capability. 

(10)  Field  and  row  coloring  depending  on  value  of  data  field  (selectable). 

(11)  Column  headings  programmable  separately  from  body  of  table. 

(12)  Non-sequential  vertical  paging  (up/reverse,  down/forward)  as  well  as 
horizontal  paging  and/or  segmentation  (i.e.,  virtual  screen)  capability. 

(13)  Scrolling  (up,  down,  left,  right)  to  augment  the  paging  feature. 

(14)  Capability  to  generate  a  hard  copy  from  a  screen  display. 

(15)  Data  error  checking  and  validation  capabilities  to  include  checking  of 

input  data  for  legal  values,  length  and  format,  as  well  as  upper  and  lower 
case  and  special  character  recognition. 

(16)  Grid  generation  capability. 

(17)  Title,  subtitle,  and  heading  generation  capability. 

(18)  Horizontal/vertical  field  count/sum  feature. 

The  Graphic  Screen  Generator  must  possess  the  following  characteristics; 

(1)  Line  Graph  and  Bar  Graph  Generators  share  some  common  capabilities: 

(a)  Variable  legends,  either  data-driven  or  user-defined. 

(b)  Automatic  x-  and  y-axis  scaling. 

(c)  Y-axis  rescaling  after  screen  display  initiated  by  a  function  key. 
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(d)  Capability  to  identify  (e.g.,  via  blinking,  changed  color,  etc.)  data 
that  has  changed  from  an  original  or  previous  data  set.  The  means 
by  which  this  "data  change  indicator"  is  activated  is  determined 
during  the  Analysis  Phase  that  precedes  each  functional  block 
implementation. 

(e)  Field  coloring  depending  on  value  of  data  field  (selectable). 

(f)  Capability  to  generate  a  hard  copy  from  a  screen  display. 

(2)  Map  Maker  capabilities: 

(a)  Linkable  to  a  special  area  on  the  screen  to  display  remarks  or  other 
data  relevant  to  the  display.  This  requires  the  routine  to  know 
where  the  cursor  is  on  the  display  in  order  to  call  up  the  correct 
information. 

(b)  A  coordinate  system  so  Air  Bases  or  other  items  of  interest  can  be 
inserted,  labeled  and  deleted  by  a  nontechnical  user  using  latitude 
and  longitude  or  Geographic  Reference  (GEOREF)  map  coordinates 
(the  positioning  will  be  reasonably  accurate  with  relation  to  one 
another). 

(c)  Coloring  of  the  base  position  according  to  the  dynamic  values  of  a 
set  of  database  variables  (the  color  indicates  a  condition  or  status). 

(d)  A  change  indicator  for  positions  whose  status  or  condition  values 
were  changed. 

(e)  Continuously  variable  software  zoom  (if  not  a  hardware  capability). 

(f)  The  capability  to  generate  and  display  special  symbols. 

(g)  Capability  to  generate  a  hard  copy  from  a  screen  display. 

Display  Screen  Parameter  Software  must  possess  the  following  characteristics: 

(1)  The  parameter  software  interacts  with  the  AFIRMS  database  when 
necessary,  to  determine,  generate,  and  list  the  appropriate  parameter 
choices  for  the  database  set  requested.  For  example,  if  ATO  3  (the  . 
specified  database  set)  does  not  have  CBU-52  munitions  (a  parameter 
selection)  tasked,  then  the  list  of  choices  for  a  munition  type  (the 
parameter)  will  not  include  CBU-52. 

(2)  The  parameter  software  is  interpretive  in  nature  so  as  to: 

(a)  Ensure  a  consistent  and  well-defined  interface  to  the  database 
transaction  software. 

(b)  Provide  a  flexible  and  user-friendly  mechanism  for  user  selection  of 
alternative  data  sets. 

(c)  Allow  the  user  to  enter  synonymous  parameter  selections;  e.g. 
"YES",  "YE",  "Y",  "OK"  can  all  be  entered  (and  subsequently 
interpreted  by  the  system)  as  an  affirmative,  instead  of  forcing  the 
user  to  precisely  reflect  database  values. 
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(3)  The  parameter  software  also  permits  write-in  choices  where  appropriate. 
In  some  instances  it  is  not  possible  or  practical  to  list  all  appropriate 
parameter  selections. 

d.  Function  Keys.  AFIRMS  is  operated  utilizing  a  system  of  menus  and  special 
function  keys.  Some  of  the  product  screen  function  keys  can  be  seen  at  the 
bottom  of  the  display  screens  described  in  the  AFIRMS  Product  Description 
annexes.  As  the  number  of  available  function  keys  is  less  than  the  number  of 
required  keys,  arrays  of  keys  are  utilized  to  overcome  that  problem. 

The  first  array  contains  the  basic  key  functions  needed  for  every  display  screen. 
Except  for  the  Base  Status  Map,  the  graphic  displays  require  only  the  first 
array.  The  tabular  input  screens  require  key  functions  to  add,  delete,  and 
change/edit  data.  A  paging  and/or  scrolling  capability  is  required.  Some  records 
have  sub-records  (e.g.,  a  wing  with  several  munitions  as  in  the  Wing  Resource 
Summary  Product,  a  mission  with  two  Aircraft  Mission  Design  Series  and/or 
aircraft  Standard  Conventional  Loads  as  in  the  Tasking  Information  product^. 
Therefore,  the  second  array  is  reserved  for  editing  records,  and  the  third  array  is 
reserved  for  editing  sub-records.  Switching  between  arrays  is  done  with  two 
special  function  keys.  An  arrow  on  either  or  both  ends  of  the  function  key  array 
shows  the  user  which  array  is  in  use.  The  required  functions  of  these  function 
keys  are  outlined  in  Table  3-1. 


3.2.2.6  User  Interface  Software.  The  primary  functions  of  this  software  subsystem  are  as 
follows: 

a.  It  provides  the  AFIRMS  user's  sole  view  of  the  AFIRMS  system. 

b.  It  serves  as  the  link  by  which  the  AFIRMS  user's  requests  are  translated  into 
internally  recognized  system  functions,  validated,  and  subsequently  performed  by 
the  system. 

The  software  providing  user  interface  to  the  AFIRMS  system  possesses  the  following 
characteristics: 

a.  Menu  driven  with  a  command  language  available  to  provide  software  capabilities 
for  experienced  users. 

b.  Consistent  menu  displays  and  underlying  definitions. 

c.  User-friendly. 

d.  Fault-tolerant. 

e.  Menu  paging  or  scrolling. 

f.  Help  available  at  all  levels  of  user/system  interaction. 

g.  Allows  for  multiple  access  paths  to  all  user  functions  (via  functional  area 
workstation  groupings,  alphabetical  lists,  logically  related  system  functions,  etc.) 
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h.  Provides  functionality  to  accept  specified  user  parameters  which  limit 
information  returned  for  screen  data  retrieval  requests. 

i.  Provides  functionality  to  allow  interactive  "through  the  display  screen"  updates  to 
the  AFIRMS  database  (as  discussed  in  section  3. 2. 2. 5  of  this  subsystem 
specification). 

j.  Detects  and  automatically  logs  off  terminals  which  have  been  inactive  for  an 
operator  definable  period  of  time.  This  time  is  determined  and  set  by  the  system 
operator. 
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PRODUCT  DISPLAY  SCREEN  FUNCTION  KEY  DESCRIPTION 


Key  Label 

Function  Description 

1st  Array: 

DISPLAY 

PARAM 

SELECT 

Takes  the  user  back  to  the  parameter  selection  screen.  The  parameter 
choices  the  user  made  to  display  the  product  are  redisplayed. 

LINE 

HIGHLIGHT 

TOGGLE 

Changes  the  state  of  the  Line  Highlighter  toggle.  If  it  is  turned/toggled  OFF, 
the  state  is  changed  to  ON  and  the  Line  Highlighter  appears.  If  it  is  toggled 

ON,  the  state  is  changed  to  OFF  and  the  Line  Highlighter  is  removed  from  the 
tabular  display.  The  function  key  is  not  active  when  a  graphic  screen  is  displayed. 

HARD 

COPY 

Spawns  a  batch  process  to  print  a  color  copy  of  the  display.  This  key  is 

on  the  1st  array  only  if  the  product  has  a  single  screen  display.  For  multiscreen 

displays,  the  key  is  on  the  2nd  array  with  the  paging  keys. 

TOP 

MENU 

Returns  the  user  to  the  first/top  menu. 

PREVIOUS 

MENU 

Returns  the  user  to  the  menu  from  which  the  product  was  selected. 

HELP 

Interrupts  the  product  display  and  takes  the  user  to  the  HELP  system.  When 
finished  with  the  HELP  screen,  the  user  returns  to  this  display. 

"i 

UPDATE 

SCREEN 

Causes  the  system  to  refresh  or  update  the  product  display  using  the 
current  parameter  choices.  Normally  used  with  a  resource  status  product  when 
the  system  notifies  the  user  that  the  status  data  has  been  updated. 

2nd  Array: 

PAGE 

REVERSE 

Page  the  product  in  reverse  order.  It  pages  a  full  or  half  page  at  a  time, 
depending  on  the  paging  option  selected.  It  is  active  only  when  a  tabular  product 
is  displayed  and  is  longer  than  one  page  of  display. 

FULL  PG 
HALF  PG 

Changes  the  paging  state  to  FULL  or  HALF  paging,  depending  on  the 
current  state.  The  current  paging  state  is  always  highlighted  or  colored. 

PAGE 

FORWARD 

Causes  the  system  to  page  the  product  forward  in  sequential  order.  It 

pages  a  full  or  half  page  at  a  time,  depending  on  the  paging  option  selected.  It  is 

active  only  as  described  in  PAGE  REVERSE  above. 

CHANGE 

XXXXXX 

DATA 

Permits  editing  of  the  screen  data.  The  'XXXXXX'  is  changed  to  the 
appropriate  term  (such  as  aircraft  or  aircrew)  when  the  product  is 
designed.  Used  only  for  tabular  products.  Pressing  the  function  key  a  second 
time  de-activates  the  CHANGE  mode. 

ADD 

XXXXXX 

DATA 

Permits  the  addition  of  a  record  to  the  database.  Used  only  for  tabular 
products.  Pressing  the  function  key  a  second  time  de-activates  the 

ADD  mode.  i, 
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.  Table  3-1  (Continued) 

. 

PRODUCT  DISPLAY  SCREEN  FUNCTION  KEY  DESCRIPTION  (Continued) 


Key  Label 

Function  Description 

DELETE 

XXXXXX 

DATA 

Permits  the  deletion  of  a  record  from  the  database.  Used  only  for  tabular 
products.  Pressing  the  function  key  a  second  time  de-activates  the 

DELETE  mode. 

ENTER 

Updates  the  data  base  as  directed  by  the  three  previous  keys  (CHANGE, 
ADD,  and  DELETE  XXXXXX  DATA).  The  ENTER  key  acts  as  a 
confirmation  step  for  the  CHANGE/ADD/DELETE  keys. 

INTERROGATE 

BASE 

Interrogates  the  cursor  position  and  displays  a  box  containing 

data  corresponding  to  the  base  displayed  under  the  cursor  (see  Base  Status 

Map). 

DELETE 

DATA  BOX 

Deletes  the  box  containing  the  base  data. 

SCALE  UP 

Increases  the  y-axis  scale  of  the  bar  graph  by  approximately  100%  after 
the  screen  is  displayed.  Used  with  bar  graphs  only. 

SCALE  DOWN 

3rd  Array: 

PAGE 

REVERSE 

FULL  PG 

HALF  PG 

PAGE 

FORWARD 

CHANGE 

XXXXXX 

DATA 

Decreases  the  y-axis  scale  of  the  bar  graph  by  approximately  50%  after 
the  screen  is  displayed.  Used  with  bar  graphs  only. 

Page  the  product  in  reverse  order.  It  pages  a  full  or  half  page  at  a  time, 
depending  on  the  paging  option  selected.  It  is  active  only  when  a  tabular 
product  is  displayed  and  is  longer  than  one  page  of  display. 

Changes  the  paging  state  to  FULL  or  HALF  paging,  depending  on  the 
current  state.  The  current  paging  state  is  always  highlighted  or  colored. 
Causes  the  system  to  page  the  product  forward  in  sequential  order.  It 
pages  a  full  or  half  page  at  a  time,  depending  on  the  paging  option 
selected.  It  is  active  only  as  described  in  PAGE  REVERSE  above. 

Same  as  CHANGE  XXXXXX  DATA  key  above  except  only  sub-record  data 
is  changed.  The  system  prevents  changes  to  record  keys/data. 

ADD 

XXXXXX 

DATA 

Same  as  ADD  XXXXXX  DATA  key  above  except  able  to  add  sub-records 
only. 

DELETE 

XXXXXX 

DATA 

Same  as  DELETE  XXXXXX  DATA  key  above  except  able  io  delete 
sub-records  only. 

ENTER 

Updates  the  data  base  as  directed  by  the  three  previous  keys  keys 
(CHANGE,  ADD,  and  DELETE  XXXXXX  DATA).  The  ENTER  key  acts  as 
a  confirmation  step  for  the  CHANGE/ADD/DELETE  keys. 

3.3  Interfaces.  AFIRMS  avoids  data  redundancy  when  possible;  however,  some 
redundancy  is  required  for  deployment  and  response  time  requirements.  AFIRMS,  where 
possible,  also  maximizes  the  use  of  USAF  (and  other  suitable  DoD  Automated  Data 
Processing  Systems  (ADPSs))  to  provide  AFIRMS  information.  This  paragraph  describes 
the  wing  subsystem  intrasite  interfaces  as  well  as  interfaces  to  the  MAJCOM  subsystem. 
Interfaces  to  external  (e.g.,  USAF,  DoD)  automated  systems  are  discussed  in  the  AFIRMS 
System  Specification. 

The  wing  subsystem  interfaces  with  the  MAJCOM  subsystem  through 
computer-to-computer  network  software  products.  These  products  link  various  operating 
systems  and  provide  the  functionality  required  to  effect  information  flows  between 
AFIRMS  subsystems. 

As  AFIRMS  intends  to  host  on  existing  hardware  and  equipments  as  much  as  possible, 
the  specific  protocols  to  be  used  are  largely  dependent  upon  existing  and/or  planned  Air 
Force  ADPSs.  Thus,  they  are  determined  or  confirmed  during  the  Analysis  Phase  that 
precedes  implementation  of  each  functional  block. 

AFIRMS  is  developed  to  take  advantage  of  currently  existing  systems  that  already 
provide  accurate  data  collection.  It  is  also  designed  to  take  advantage  of  systems  that 
produce  capability  assessments  using  a  subset  of  the  resources  AFIRMS  ultimately  uses  to 
produce  its  capability  assessments.  In  order  to  handle  interfaces  with  future  developing 
systems,  AFIRMS  is  designed  modularly  with  generic  data  gateway  interfaces.  As  these 
new  systems  are  implemented,  they  can  easily  be  interfaced  with  AFIRMS.  These  generic 
interfaces  apply  to  communications  networks  as  well  as  data  systems. 

AFIRMS  is  data  collection  intensive.  However,  AFIRMS  attempts  to  minimize 
duplication  of  the  collection  of  any  data  that  is  already  being  collected  by  another  system 
(e.g.,  munitions  data  collected  by  Combat  Ammunition  System  (CAS)).  In  addition, 
AFIRMS  does  not  compute  an  assessment  that  is  already  available  in  another  system  (e.g., 
spares  analysis  computed  by  Combat  Supplies  Management  System  (CSMS)). 

3.3.1  AFIRMS  Intrasite  Interfaces.  The  transactions  that  occur  within  a  particular 
AFIRMS  site  require  three  types  of  interface  specifications: 


a. 


Intrasite  Transaction  Header.  This  interface  specification  defines  the  format 
of  the  information  required  to  transmit  any  transaction  to/from  the  CNM 
from/to  any  functional  area  workstation. 


Appendix  A  provides  tfye  detailed  specification  of  the  information  contained  in 
this  header  interface. 


b.  Display  Screen  Interfaces.  These  interface  specifications  define  the  format  of 
the  data  that  is  retrieved  on  behalf  of  the  functional  user  in  accordance  with 
his/her  input  parameters  and  subsequently  transmitted  to  the  functional  area. 
Each  of  these  interface  specifications  also  requires  an  Intrasite  Transaction 
Header  as  defined  above. 

Table  3-2  provides  a  cross-reference  between  the  AFIRMS  output  reports  set 
forth  in  Section  4.3.2  of  this  subsystem  specification  and  the  AFIRMS  internal 
interface  specifications  provided  in  Appendix  B. 

c.  Data  Update  and  Retrieval  Transaction  Interfaces. 

The  logical  data  flow  for  data  update  and  retrieval  transactions  is  provided  in 
Tables  3-3  and  3-4  respectively. 

Tables  3-5  and  3-6  provide  the  interface  specifications  for  the  data  update  and 
data  retrieval  requests,  respectively.  Each  of  these  requests  also  requires  an 
Intrasite  Transaction  header  as  defined  above. 


Table  3-2 


AFIRMS  OUTPUT  REPORT 
(Cross-Reference  to  Appendix  B) 


Screen  Title 

Interface 

Spec.  Appendix 
Cross-Reference 

AGE  Availability  Status 

APIB/S 

AGE  Support  Capability 

APIB/S 

Aircraft  <5t  Mission  Tasking  Details 

APIB/S 

Aircraft  Availability 

B-6 

Aircraft  Capability 

B-6 

Aircraft  Spares  Support  Capability 

APIB/S 

Aircraft  Status 

B-l 

Aircraft  Tasking 

B-2 

Aircrew  Availability 

B-l 

Aircrew  Capability 

B-6 

Aircrew  Generation 

B-5 

Aircrew  Status 

B-l 

Airfield  Status 

APIB/S 

Base  Fuels  Capability 

B-2 

Base  Status  (Input) 

B-l 

Base  Status  (Output) 

B-l 

Flying  Schedule  (Maintenance) 

B-l 

Flying  Schedule  (Operations) 

B-l 

Fuels  Capability 

APIB/S 

Fuels  Status 

B-l 

Fuels  Status  Map 

APIB/S 

Individual  Resource  Capability 

B-2 

Integrated  Capability 

B-2 

Maintenance  Support  Capability 

APIB/S 

Mass  Load  Generation  Schedule 

APIB/S 

Mission  Flow 

APIB/S 

Mission  Profile  Definition 

B-l 

Munition  Flow 

APIB/S 

Munitions  A  &  D  Availability 

APIB/S 

Munitions  Assembly  Capability 

APIB/S 

Munitions  Availability  Forecast 

B-4 

Munitions  Capability 

B-2 

Munitions  Distribution  Capability 

APIB/S 

Munitions  Load  Capability 

APIB/S 

Munitions  Load  Crew  Available 

APIB/S 

Munitions  Load  Crew  Flow 

APIB/S 

Munitions  Status 

B-l 

OPlan/OPORD  Associations 

B-l 

Order  Assignments 

B-l 

Process  Status 

B-l 

*  AP1B/S  -  Analysis  Phase  Initial  Block  for  each  Segment 


Table  3-2  (Continued) 


AFIRMS  OUTPUT  REPORT 
(Cross-Reference  to  Appendix  B) 


Refueling  Capability 
Refueling  Truck  Flow 
Single  Aircraft  Summary 
Supply  MICAP  Status 
Task  Capability 
Tasked  Missions 
Tasked  Munitions 
Tasking  Information 
Unit  Status  (Output) 

War  Mobilization  Plan 
Wing  Flying  Day 
Wing  Operations  Rates 
Wing  Resource  Summary 
Wing  Resupply  Schedule 


Interface 
Spec.  Appendix 
Cross-Reference 


APIB/S 

APIB/S 

APIB/S 

B-l 

APIB/S 

B-6 

B-6 

B-l 

B-l 

B-l 

B-l 

B-l 

B-l 

B-l 


*  APIB/S  -  Analysis  Phase  Initial  Block  for  each  Segment 
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TABLE  3-3a 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Functional  Area  Workstation) 


User  logs  onto  FAW  by  entering  username  and  password. 

If  username/password  combination  is  invalid,  then 

The  FAW  keeps  track  of  the  number  of  consecutive  times  this  occurs,  as  well  as  the 
invalid  information. 

If  invalid  information  has  been  entered  three  times  in  a  row,  then 

FAW  logically  locks  the  terminal  from  further  use  by  saving  the  information  on 
the  disk  and  indicating  that  state. 

FAW  generates  a  siren-like  sound  indicating  the  security  violation. 

FAW  displays  the  security  violation  screen. 

FAW  sends  to  the  ACNM  (if  possible)  a  security  message  indicating  the  problem. 
The  ACNM  notifies  the  security  officer  via  three  ways: 

( 1)  Sends  a  message  directly  to  his/her  terminal  if  he/she  is  logged  on. 

(2)  Sends  a  security  message  to  his/her  mailbox. 

(3)  Sends  the  security  message  to  the  system  manager's  hardcopy  device. 

Else 

FAW  gives  user  another  chance  to  logon  properly. 

Endif 

Else  [valid  user  logon  has  occurred  on  the  FAW] 

FAW  attempts  to  logon  to  the  ACNM  by  passing  the  username/password  entered. 

The  ACNM  performs  security  checks. 

If  a  security  violation  has  been  detected,  then 

ACNM  logically  locks  the  terminal  port  from  further  use  by  saving  information  on 
the  disk  and  indicating  that  state. 

The  ACNM  notifies  the  security  officer  via  three  ways: 

( 1)  Sends  a  message  directly  to  his/her  terminal  if  he/she  is  logged  on. 

(2)  Sends  a  security  message  to  his/her  mailbox. 

(3)  Sends  the  security  message  to  the  system  manager's  hardcopy  device. 

The  ACNM  tells  the  FAW  of  the  security  violation. 

Else  [valid  user  logon  has  occurred  on  the  ACNM] 

AFIRMS  processes  are  started  that  run  on  the  user's  behalf. 

If  there  is  no  problem  starting  these  processes,  then 

AFIRMS  code  and  data  needed  for  the  user  are  downloaded. 

If  all  necessary  data  and  code  reach  the  FAW  successfully,  then 

The  ACNM  gets  ready  for  requests  from  the  FAW  on  behalf  of  the  user. 

The  ACNM  tells  the  FAW  that  fact. 

Else 

There  is  a  problem. 

Endif 

Endif 
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TABLE  3-3a 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Functional  Area  Workstation)  (Continued) 


If  there  is  a  problem  on  the  ACNM,  then 

The  ACMN  informs  the  FAW  of  the  problem. 

The  ACNM  logs  the  user  off  AFIRMS. 

The  FAW  notifies  the  user  of  the  problem. 

If  a  local  database  for  this  user  exists  from  a  previous  logon,  then 
the  user  is  allowed  to  make  requests  of  his/her  local  database  only. 

Else 

The  FAW  notifies  the  user  of  the  problem. 

The  FAW  logs  the  user  off  AFIRMS. 

Endif 

Endif 

Endif 

Endif 

[CNM  checks  for  data  stored  on  behalf  of  the  user  on  non-volatile  random  access  medium.] 
If  ACNM  finds  data  destined  for  the  user,  then 
ACNM  sends  FAW  user  data  summary. 

Endif 

ACNM  sends  FAW  the  currently  available  CPU/processing  power  for  each  CNM. 

FAW  notifies  user  of  data  stored  on  his/her  behalf  (e.g.,  previous  request,  mail). 

If  user  chooses  details  of  his/her  CNM  data,  then 
FAW  displays  user  data  summary. 

[User  selects  which  data  he/she  wishes  to  view/delete.] 

Endif 

If  user  wishes  to  view/delete  a  dataset,  then 

If  ACNM  can  be  talked  to  via  normal  communications  link  or  dial-up,  then 
The  view/delete  request  is  transmitted  to  the  ACNM. 

Else 

The  user  is  notified  that  there  is  a  problem. 

The  user  is  asked  to  make  another  request. 

Endif 

Endif 


TABLE  3-3a 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Functional  Area  Workstation)  (Continued) 


FAW  user  requests  screen  for  viewing  via  FAW  MMI. 

[FAW  database  is  checked  for  required  data.] 

If  all  data  exists  (is  resident)  locally,  then 

FAW  software  determines  if  the  response  time  would  be  faster  by  allowing  a  CNM  to 
perform  the  request. 

If  processing  is  faster  on  the  CNM,  then 
The  request  is  transmitted  to  the  ACNM. 

Else  (processing  is  faster  locally] 

The  FAW  handles  the  request  locally. 

Endif 

Else  [some  or  all  of  the  data  exists  elsewhere] 

The  user  is  informed  that  his/her  request  requires  access  to  the  CNM's  database. 

The  user  is  asked  for  confirmation  of  the  request. 

If  the  user  confirms  the  request,  then 

If  the  ACNM  can  be  talked  to  via  normal  link  or  dial-up,  then 
The  request  is  transmitted  to  the  ACNM. 

Else 

The  user  is  notified  there  is  a  problem. 

The  user  is  requested  to  make  another  screen  selection. 

Endif 

Else  [the  user  didn't  confirm  the  request] 

The  user  is  requested  to  make  another  screen  selection. 

Endif 

Endif 


Acronym  Definitions 


ACNM  -  the  CNM  directly  attached  to  the  user's  FAW 

AFAW  -  all  functional  area  workstations  attached  to  an  ACNM 

CNM  -  central  node  module/manager 

FAW  -  functional  area  workstation 

MMI  -  man-machine  interface 

NCNM  -  CNM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 
request  was  being  processed) 

NFAW  -  newly  logged-onto  FAW 

OCNM  -  original  CNM  that  received  a  FAW  request 

OFAW  -  original  FAW  that  made  a  request 

PCNM  -  the  CNM  that  actually  performed  the  FAW  request 
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TABLE  3-3b 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Central  Node  Manager) 


The  ACNM  receives  a  FAW  request  for  data  retrieval. 

[The  OCNM  determines  which  CNM  can  best  process  the  request.] 

If  the  request  should  be  handled  by  a  "different"  CNM,  then 

The  request  is  transmitted  to  the  CNM  that  can  best  handle  it. 

Endif 

If  there  are  requests  currently  queued,  then 

[A  separate  queue  is  maintained  for  updates.  It  is  always  serviced  before  the  query  queue 
in  order  to  minimize  database  conflicts.] 

The  request  is  queued  according  to  priority  using  a  FIFO  algorithm. 

As  requests  are  completed,  the  next  request  performed  is  the  one  at  the  top  of  the 
highest  priority  queue  with  a  request  currently  queued. 

Else  [there  are  no  other  requests  queued] 

The  request  is  performed  immediately. 

The  PCNM  transmits  to  each  AFAW  and  all  other  CNMs  its  currently  available 
(unused)  CPU/processing  power. 

Endif 

The  CNM  that  processes  the  request  transmits  to  each  attached  FA  and  all  other  CNMs 
its  currently  available  processing  power.  Each  of  the  "other"  CNMs  also  transmits  this 
processing  capability  to  its  FAWs. 

[When  an  interactive  request  is  completed,  the  results  are  sent  back  to  the  requesting 
user.] 

If  the  reauest  was  handled  by  other  than  the  OCNM,  then 

[First  a  check  is  made  to  see  if  the  user  is  still  logged  onto  any  of  the 
OCNM's  FAWs.] 

If  the  PCNM  can  talk  to  the  OCNM,  then 

The  PCNM  sends  a  "check  if  the  user  is  still  *ogged  on"  request  to  the  OCNM. 

The  OCNM  sends  a  response  to  the  PCNM. 

If  the  user  is  still  logged  onto  the  OCNM,  then 
The  PCNM  transmits  the  results  to  the  OCNM. 

Elseif  the  user  is  logged  onto  any  of  the  PCNM's  FAWs,  then 
The  PCNM  transmits  the  results  to  the  user's  NFAW. 
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TABLE  3-3b 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Central  Node  Manager)  (Continued) 


Elseif  the  PCNM  can  talk  to  the  other  CNMs,  then 

The  PCNM  sends  a  "check  if  user  is  still  logged  on"  request  to  each  of  the  other 
CNMs  in  sequence  to  determine  if  the  user  is  logged  onto  any  other  CNM's  FAWs. 

If  the  user  is  not  logged  onto  the  system,  then 
The  PCNM  transmits  the  results  to  the  OCNM. 

The  OCNM  saves  the  results  on  a  non-volatile,  random  access  medium  for 
later  use. 

Else 

The  PCNM  transmits  an  "asynchronous  event"  message  to  the  CNM  which 
is  attached  to  the  NFAW  the  user  is  logged  onto. 

That  CNM  then  transmits  the  message  to  the  user's  NFAW. 

End  if 

Else  [the  communications  links  between  the  CNMs  not  working] 

The  PCNM  saves  the  results  on  non-volatile,  random  access  medium  for  later  use. 
End  if 

Else  [communications  link  between  the  PCNM  and  the  OCNM  not  working] 

If  the  user  is  logged  onto  any  of  the  PCNM's  FAWs,  then 
The  PCNM  transmits  the  results  to  the  user's  NFAW. 

Else 

The  PCNM  saves  the  results  on  non-volatile,  random  access  medium  for  later  use. 
Endif 
Endif 
Endif 

If  the  user  is  logged  onto  any  FAWs  when  his/her  request  completes,  then 

The  ACNM  transmits  the  results  to  the  user's  FAW  regardless  of  whether  the  user 
is  logged  onto  the  OFAW  from  which  the  request  was  made,  or  a  NFAW. 

Endif 

The  PCNM  must  transmit  to  each  attached  FA  and  all  other  CNMs  its  available  CPU/ 
processing  capability.  This  capability  is  used  by: 

(1)  The  FAWs  to  determine  if  a  CNM  can  handle  a  request  faster,  and 

(2)  The  CNMs  to  determine  which  CNM  can  handle  a  request  faster. 


Acronym  Definitions 

ACNM  -  the  CNM  directly  attached  to  the  user’s  FAW 
AFAW  -  all  functional  area  workstations  attached  to  an  ACNM 
CNM  -  central  node  module/manager 
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TABLE  3-3b 


FAW 

MMI 

NCNM 

NFAW 

OCNM 

OFAW 

PCNM 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  RETRIEVAL  TRANSACTIONS 
(Central  Node  Manager)  (Continued) 


functional  area  workstation 
man-machine  interface 

CNM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 
request  was  being  processed) 
newly  logged-onto  FAW 
original  CNM  that  received  a  FAW  request 
original  FAW  that  made  a  request 
the  CNM  that  actually  performed  the  FAW  request 
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TABLE  3-4a 

DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Functional  Area  Workstation) 


After  reviewing  the  retrieved  data,  the  user  updates  a  record. 

The  editor  does  not  allow  the  user  to  change  any  field  that  he/she  does  not  have  privilege  for. 

The  OFAW  sends  the  updated  record  (including  its  keys)  to  the  ACNM. 

The  OFAW  also  updates  its  local  database.  A  copy  of  the  "before"  and  "after”  database 

record  images  is  saved  in  case  the  update  must  be  backed  out. 

[Note:  The  user  is  not  prevented  from  making  further  requests  of  AFIRMS  at  this  point.  All 
messages  from  the  ACNM  occur  asynchronously.  The  user  is  notified  each  time 
asynchronous  messages  occur.  At  that  point,  he/she  can  request  a  display  containing  a  list 
of  all  asynchronous  events  pertaining  to  him/her.  This  display  is  a  temporary  "window" 
which  is  used  only  for  viewing  any  asynchronous  events.  It  cannot  be  used  for  any  screen 
which  can  be  requested  via  the  normal  screen  selection  list.  This  window  can  also  be  looked 
at  via  the  normal  screen  selection  list.  Viewing  of  this  screen  does  not  in  any  way  destroy 
the  state  of  the  screen  the  user  was  viewing  prior  to  looking  at  the  window.  That  is,  after 
the  user  has  completed  viewing  the  window,  the  next  screen  seen  is  the  one  the  user  was 
viewing  at  the  time  he/she  requested  to  look  at  the  window,  restored  to  its  original  state.] 

For  all  other  FAWs  receiving  the  changed  information  from  their  ACNM, 

The  local  database  is  updated  with  the  changed  information. 

If  the  user  is  currently  looking  at  the  changed  information,  then 
The  FAW  indicates  to  the  user  that  a  change  has  occurred. 

The  user  can  then  look  at  the  screen  via  a  window  that  contains  all 
asynchronous  events,  if  desired. 

Endif 

Endfor 

If  the  OFAW  receives  a  security  violation  message  from  the  ACNM,  then 

The  OFAW  logically  locks  the  terminal  from  further  use  by  saving  the  information  on 
the  disk  and  indicating  that  state. 

The  OFAW  generates  a  siren-like  sound  indicating  the  security  violation. 

The  OFAW  displays  the  security  violation  screen. 

The  OFAW  backs  out  the  update  that  was  attempted. 

The  OFAW  deletes  the  "before"  and  "after"  database  record  images. 

Elseif  the  OFAW  cannot  send  a  message  to  its  ACNM  because  of  communications 

problems,  then 

The  OFAW  backs  out  the  update  that  was  made  previously. 

The  OFAW  deletes  the  "before"  and  "after"  database  record  images. 

The  OFAW  allows  the  user  to  continue  making  other  requests. 

Elseif  the  OFAW  receives  a  processing  error  message  from  the  ACNM,  then 

The  ACNM  saves  the  update  information  on  non-volatile  random  access  medium  for 
later  use  in  attempting  to  update  the  cental  database. 

The  OFAW  deletes  the  before  and  after  database  record  images. 

Endif 
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DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Functional  Area  Workstation) 


Acronym  Definitions 

ACNM  -  the  CNM  directly  attached  to  the  user's  FAW 

AFAW  -  all  functional  area  workstations  attached  to  an  ACNM 

CNM  -  central  node  module/manager 

FAW  -  functional  area  workstation 

MMI  -  man-machine  interface 

NCNM  -  NM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 
request  was  being  processed) 

NFAW  -  newly  logged-onto  FAW 

OCNM  -  original  CNM  that  received  a  FAW  request 

OFAW  -  original  FAW  that  made  a  request 

PCNM  -  the  CNM  that  actually  performed  the  FAW  request 
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DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Central  Node  Manager) 


The  ACNM  receives  an  OF  AW  update  request. 

[The  OCNM  determines  whether  the  update  request  should  be  processed  immediately 
or  not.] 

If  there  are  other  update  requests  in  the  update  queue,  then 

The  update  request  is  queued  at  the  end  of  the  update  queue. 

As  update  requests  are  completed,  the  request  that  is  at  the  top  of  the  update  queue 
is  performed. 

Endif 

[The  OCNM  performs  a  security  check  to  make  sure  the  user  is  allowed  to  make  the 
update  to  the  database.] 

If  the  user  is  not  allowed  to  make  the  update  [a  security  violation  has  occurred]  tnen 
The  OCNM  informs  the  FAW  of  the  problem. 

The  OCNM  notifies  the  security  officer  via  three  ways: 

(1)  Sends  a  message  directly  to  his/her  terminal  if  he/she  is  logged  on. 

(2)  Sends  a  security  message  to  his/her  mailbox. 

(3)  Sends  the  security  message  to  the  system  manager's  hardcopy  device. 

Else  [the  user  is  allowed  to  make  the  update] 

The  OCNM  attempts  to  update  the  central  database. 

If  the  user  making  the  update  request  is  still  logged  onto  the  OF  AW,  then 
The  OCNM  sends  the  update  status  back  to  the  OFAW. 

Else 

The  OCNM  saves  the  update  status  on  non-volatile  random  access  medium  for 
later  use. 

Endif 

[The  OCNM  determines  whether  other  CNMs  need  that  update  information.] 

If  other  CNMs  need  the  update  information,  then 

It  is  sent  to  them.  In  addition  to  the  changed  information,  the  time/date  of  the 
update,  as  well  as  the  username  of  the  person  that  made  the  change,  are  sent. 
Endif 

All  CNMs  that  receive  updated  information  must  send  those  changes  to  each  of  their 
AFAWs  that  currently  have  a  local  database  containing  that  record. 

[DatA  consistency  checks  are  made.] 

If  other  data  within  the  central  database  is  inconsistent  with  the  newly  updated 
information,  then 

That  data  is  made  consistent  by: 

(1)  intelligent  software,  or 

(2)  requesting  the  user  to  make  other  information  consistent;  otherwise  the  original 
change  is  backed  out  and  all  FAWs  originally  receiving  that  change  are  notified. 

Endif 

Endif 
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Acronym 

ACNM 

AFAW 

CNM 

FAW 

MMI 

NCNM 

NFAW 

OCNM 

OFAW 

PCNM 


DESCRIPTION  OF  DATA  FLOW 
FOR 

DATA  UPDATE  TRANSACTIONS 
(Central  Node  Manager)  (Continued) 


Definitions 


-  the  CNM  directly  attached  to  the  user's  FAW 

-  all  functional  area  workstations  attached  to  an  ACNM 

-  central  node  module/manager 

-  functional  area  workstation 

-  man-machine  interface 

-  NM  that  the  user  is  newly  attached  to  (assuming  he  logged  off  while  his 
request  was  being  processed) 

-  newly  logged-onto  FAW 

-  original  CNM  that  received  a  FAW  request 

-  original  FAW  that  made  a  request 

-  the  CNM  that  actually  performed  the  FAW  request 
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Table  3-5 

CNM  DATA  RETRIEVAL  REQUEST  INTERFACE  SPECIFICATION 


CNM  Data  Retrieval  Request 
Interface  Specification 


Date:  31-May-1985 


The  CNM  Data  Retrieval  Request  buffer  layout  is  as  follows 


Screen  // 
requested 


//  of  parameters 
to  follow 


Repeats  //  of  parameters  to  follow  times 


Parameter 

number 


Parameter 

selection 

number 


Length  of 

parameter 

value 


Parameter 

value 


Field  Name 

Screen  number  requested 
Number  of  parameters  to  follow 
Parameter  number 
Parameter  selection  number 
Length  of  parameter  value 
Parameter  value 


Field  Length 


_ J 


♦§2 


Note:  Each  field  whose  length  is  represents  a  variable  length  field.  Only  these 
fields  are  preceded  by  a  2-byte  length  descriptor  field. 
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CNM  DATA  UPDATE  REQUEST  INTERFACE  SPECIFICATION 

CNM  Update  Request  Interface  Specification  Date:  31-May-1985 
The  CNM  Update  Request  buffer  layout  is  as  follows: 

—  Repeats  for  the  number  of  keys  for  this  screen 


Screen  // 
for  update  j 


Column  // 
for  screen 


Length  of 
key  value 


Key 

value 


Repeats  <(//  of  changes  to  follow^  times 


to  follow 


Field  Name _ 

Screen  //  for  update 
Column  //  for  screen 
Length  of  key  value 
Key  value 

//  of  changes  to  follow 
Column  //  for  screen  to  modify 
Length  of  new  value 
New  value 


Column  //  for 

Length  of 

New 

screen  to  modify 

new  value 

value 

Field  Length 


Note:  Each  field  whose  length  is  represents  a  variable  length  field.  Only  these 
fields  are  preceded  by  a  2-byte  length  descriptor  field. 
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3.4  Security.  THE  AFIRMS  ADPS  processes  noncritical-sensitive  data  as  defined  in 
Attachment  6  to  AFR  205-16.  The  operational  AFIRMS  system  handles  users  and  data  at 
classification  levels  from  Unclassified  to  Secret.  There  are  Top  Secret  AFIRMS-related 
data  at  the  wing  level.  However,  due  to  limitations  of  controlled  mode  operations, 
AFIRMS  does  not  initially  handle  Top  Secret  data.  AFIRMS  capability  assessments 
involving  Top  Secret  data  are  accomplished  manually.  When  multilevel  security 
procedures  are  available,  the  controlled  mode  security  limitations  can  be  reevaluated 
during  the  analysis  phases  of  each  implementation  block.  More  specifically,  wing  sites 
have  personnel  with  a  need-to-know  of  Unclassified  through  Secret.  Some  wing  personnel 
have  need  to  input  or  access  unclassified  data  resident  at  wing  user  terminals.  Thus,  an 
operational  AFIRMS  wing  site  must  handle  simultaneously  a  mix  of  user  data,  and  user 
terminal  security  classifications.  Therefore,  sites  at  the  wing  level  operate  in  the 
Controlled  Security  Mode.  This  is  accomplished  by  utilizing  a  combination  of  the 
following  security  measures: 


a.  Personnel  Security.  All  personnel  having  access  to  MA3COM  and  HQ  USAF 
AFIRMS  facilities  and/or  data  have  a  security  clearance  equal  to  the  highest 
level  of  classification  being  processed,  stored,  or  displayed.  At  all  AFIRMS 
sites,  each  user's  identity  is  positively  established  via  user  IDs  and  log-on 
passwords  (terminal  display  of  which  is  suppressed),  which  are  used  to 
authenticate/verify  AFIRMS  users'  identities  and  their  corresponding  access 
privileges.  AFIRMS  provides  a  capability  to  prevent  unauthorized  users  from 
executing  a  protected  program  or  series  of  programs. 

A  personnel  security  program  is  implemented  for  the  AFIRMS  program  in 
accordance  with  the  provisions  of  DoD  Regulation  5200.2/AFR  205-32  USAF 
Personnel  Security  Program.  Personnel  access  controls  are  implemented  for 
the  AFIRMS  central  computer  facilities  and  remote  terminal  areas. 

(1)  Central  Computer  Facility.  Strict  personnel  access  controls  are 
implemented  to  ensure  that  the  only  personnel  admitted  are  those  who 
require  access  to  the  central  computer  facility,  and  possess  a  security 
clearance  at  least  equal  to  the  highest  classification  of  information  being 
processed  or  openly  stored  at  the  facility. 

(2)  Remote  Terminal  Area(s).  Authorization  for  access  to  and  the  use  of 
remote  terminal  devices  is  based  on  an  individual's  duties,  his/her  need  to 
use  the  terminal,  and  possession  of  a  security  clearance  of  the  required 
level. 

b.  Physical  Security.  Measures  must  be  taken  to  ensure  external  protection  for 
AFIRMS  against  unauthorized  access  to  the  central  computer  facility,  to  the 
system  from  remote  terminals,  and  to  data  storage  media. 

(1)  Central  Computer  Facility.  Central  computer  facility  physical  security 
must  meet  the  requirements  established  for  the  highest  classification  and 
all  sensitivity  categories  of  data  that  are  either  resident  in  the  ADPS  or 
openly  stored. 

SORbi 
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(2)  Remote  Terminal  Area(s).  Physical  security  measures  at  remote  sites 
must  fulfill  the  minimum  requirements  for  the  highest  classification  of 
information  accessed  from  or  stored  at  the  site. 

Hardware  Security.  AFIRMS  system  hardware  meets  ail  of  the  provisions 
recommended  in  DoD  5200. 28M,  ADP  Security  Manual  for  hardware  security 
features. 

Software  Security.  The  operating  systems  selected  for  use  meet  the  general 
software  security  requirements  stated  in  DoD  5200. 28M.  In  addition  to  the 
security  protection  features  contained  in  the  operating  systems,  a  combination 
of  system  and  application  software  protection  features  are  utilized  to  provide 
the  following  security  protection  to  comply  with  applicable  DoD  and  Air  Force 
security  policies. 

(1)  Access  Control  to  prevent  unauthorized  entry  to  systems,  files  and 
programs.  Wings  cannot  query  HQ  USAFE  (MAJCOM-level)  data, 
information  flow  will  be  one-way  (upwards)  from  wings  to  HQ  USAFE  in 
order  to  maintain  (at  HQ  USAFE)  access  control  of  Top  Secret  data. 

(2)  File  Security  to  prevent  unauthorized  access  or  alterations  to  files. 

(3)  Error  Surveillance  and  Alerts  to  recognize,  record  and  indicate  misuse  of 
the  system. 

(4)  File  Security  to  prevent  unauthorized  access  or  alterations  to  files.  An 
automated  audit  trail  will  show:  access  made  to  files;  how,  and  from 
where  the  access  was  initiated;  the  identity  of  the  person  or  process  that 
initiated  the  access;  and  all  unauthorized  attempts. 

(5)  User  Monitoring  and  Isolation  to  ensure  the  user  has  access  to  only  the 
system  information  to  which  he  is  entitled. 

System  Stability.  All  AFIRMS  components  operate  so  that  one  can 
automatically  or  administratively  detect  and  report  system  hardware  and 
software  malfunctions  in  time  to  prevent  unauthorized  disclosure. 

Data  Integrity.  Each  database,  file,  and  data  set/element  is  identified  with  an 
origin,  use,  and  an  explicitly  defined  set  of  access  controls.  These  access 
controls  are  based  on  classification,  sensitivity,  user  clearance,  and  established 
need-to-know. 

National  Bureau  of  Standards  (NBS)  or  National  Security  Agency  (NSA) 
approved  data  encryption  devices  may  be  required  for  transmission  of  sensitive 
unclassified  data  depending  on  the  nature  of  the  data. 

Emanations  Security  (EMSEC).  ADP  and  communications  equipment  utilized  to 
process  classified  material  at  AFIRMS  sites  will  be  TEMPEST  approved.  All 
devices  that  are  not  TEMPEST  approved  will  be  tested  and  approved  for 
placement  in  the  ADP  facilities  in  such  a  manner  as  to  control  compromising 
emanations.  All  equipment  will  be  installed  IAW  the  guidelines  stated  in 
NACSIM  5203. 


i.  Procedural  Security.  Security  operating  procedures  will  meet  the  requirements 
of  AFR  205-1  and  205-16  and  include  the  following: 

(1)  System  Access  Controls 

(2)  File  Access  Controls 

(3)  Personnel  Access  Controls 

(4)  Security  Markings 

(5)  Protecting  Classified  Output 

(6)  Physical  Security 

(7)  Protection  of  Residual  Information 

(8)  Declassification  Guidelines 


3.5  Controls.  The  AFIRMS  Wing  subsystem  requires  integrated  control  functions  which 
operate  at  system  levels  independent  of  stated  AFIRMS  operational  functionality.  These 
functions  are  implemented  and  utilized  so  as  to  minimize  their  impact  on  AFIRMS 
execution. 

Control  functions  are  logically  separated  into  two  functional  categories; 
System/Operations  Management  Controls,  and  Intrasite  Access  and  Data  Flow  Controls. 


3.5.1  System/Operations  Management  Controls. 


These  controls  incorporate  the  following 


functions: 


a.  The  application  of  software  monitoring  and  diagnostic  utilities. 

b.  The  application  of  hardware  monitoring  and  diagnostic  utilities. 

c.  The  ability  to  start,  stop,  and  restart  AFIRMS  system  and  communications 
processes,  including  upper-level  control  of  network  performance. 

d.  The  ability  to  alter  AFIRMS  subsystem  runtime  parameters  dynamically  (e.g., 
process  priorities,  operating  system  parameters,  etc.) 
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3.5.2  Intrasite  Access  and  Data  Flow  Controls.  These  functions  address  control 
requirements  imposed  by  security  and  data  integrity  issues.  They  also  assist  in  supporting 
downgraded  operational  modes.  These  functions  include: 


a.  Dynamic  imposition  of  limitations/new  priorities  on  intrasite  data 
communications  to  and/or  from  specific  functional  areas. 

b.  Dynamic  limitations/alterations  of  data  access  and/or  data  modification 
authorizations  for  specific  functional  areas. 
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SECTION  4.  DESIGN  DETAILS 


4,1  General  Operating  Procedures.  After  AF1RMS  is  installed,  user/operator  manuals 
guide  system  operation.  The  user/operator  manuals  contain  instructions  on  how  to  turn 
equipment  on  and  off,  as  well  as  clear,  concise  instructions  for  the  operation  of  AFIRMS. 
Operating  procedures  for  both  the  system  software,  hardware,  and  functional  products  are 
provided  as  a  combination  of  vendor-provided  documents  and  AF1RMS  user  manuals.  The 
vendor-supplied  documents  detail  hardware  and  system  software  procedures  while 
AFIRMS  user  manuals  detail  functional  product  procedures  including  communications  and 
security.  The  manuals  are  written  in  sufficient  detail  to  enable  the  system  user  to 
respond  to  most  situations  he/she  may  encounter.  The  specific  requirements  for  AFIRMS 
user/operator  manuals  are  determined  during  the  in-depth  analysis  that  precedes 
implementation  at  each  AFIRMS  site. 


4,1.1  System  Start,  Restart,  and  Stop  Times.  Maximum  system  start,  restart,  and  stop 
times  are  provided  below.  AFIRMS  hardware  must  accommodate  these  times.  All 
specified  times  are  non-data  communications  related;  i.e.,  they  do  not  include  the  amount 
of  time  that  may  be  required  to  transfer  additional  required  data  from  the  CN  to  the  FA 
upon  system  startup.  Data  communications  times  are  dependent  upon  the  data 
distributions  at  each  AFIRMS  site.  These  times  presume  a  booted  and  ready  Central 
Processing  Unit  (CPU);  that  is  to  say,  times  exclude  host  machine  power  up  and  initial 
bootstrap. 


Central  Node  Functional  Area 

System  Start 
System  Restart* 

System  Stop  (Down) 


30  seconds 
60  seconds 
60  seconds 


30  seconds 
1 20  seconds 
1 20  seconds 


*  Precise  definition  and  features  of  the  System  Restart  shall  be  reviewed  and 
determined  during  the  analysis  phase  that  precedes  implementation  at  each 
site. 


4.2  Wing  Subsystem  Logical  Flow.  AFIRMS  logical  and  intrasite  information  flow  is 
shown  in  Figures  4-1  and  4-2,  respectively.  Squadrons  are  linked  hierarchically  to  a  wing 
which  is  linked  hierarchically  to  a  MA3COM,  which  in  turn  is  linked  to  HQ  USAF. 


AFIRMS  is  a  "push"  system  only.  This  means  that  there  is  upward  reporting  of  data 
at  regular  intervals,  with  no  provision  for  ad-hoc  querying  of  databases  between  sites. 

The  data  accessible  at  AFIRMS  sites  is  at  the  level  of  detail  appropriate  to  the  particular 
command  level.  However,  flexibility  to  increase  the  frequency  of  upward  reporting  cycles 
is  provided  for  exception  reporting  on  a  case-by-case  basis.  Implementation  of  this 
exceptional  reporting  requirement  is  procedural  in  nature,  and  thus  external  to  AFIRMS. 


Figure  4-1.  AFIRMS  Logical  Flow 


4.3  Subsystem  Data.  Wing  sites  operate  on  the  following  types  of  data: 


a.  Tasking  Data.  Tasking  data  consists  of;  Designed  Operational  Capability  (DOC) 
statements,  OPlans/OPORDs,  special  ad  hoc  taskings  from  HQ  USAFE,  and 
NATO  support  and  tasking  requirements  from  the  ATOC. 

b.  Resource  Data.  Resource  data  is  data  collected  and  maintained  by  the  wing 
squadrons  and  consists  of  aircraft  status,  aircrew  status,  fuels  status,  munitions 
status,  and  (for  later  implementation  blocks)  logistics  support  status. 

c.  Theatre  resource  data  such  as  depot  level  fuels  and  munitions  is  maintained  and 
provided  by  depots  and  support  units  via  automated  systems  such  as  CAS, 

CFMS,  etc. 


1.  ON  A  PERIODIC  BASIS  (AT  A  MINIMUM. 
EVERY  (  HOURS).  OR  ON  REQUEST  FROM 
A  HICHER-LEVEL  SITE.  DATA  THAT  HAS 
BEEN  UPDATED  VIA  THE  WING  LEVEL 
FUNCTIONAL  AREAS  IS  ROLLED  UP 
(ACCRECATED)  AND  TRANSMITTED  TO 
THE  MAJCOM  LEVEL. 

2.  THE  CENTRAL  NODE  MODULE  SENDS 
NOTIFICATION  OF  DATA  UPDATE  TO 
OTHER  FUNCTIONAL  AREAS  AFFECTED. 

3.  THE  CENTRAL  NODE  MODULE  UPDATES 
THE  CENTRAL  DATABASE. 

«  UPDATED  DATA  IS  PASSED  TO  THE 
CENTRAL  NODE  MODULE. 

S.  DATA  IS  UPDATED  AT  THE  FUNCTIONAL 

'  AREA. 


Figure  4-2.  AFIRMS  Wing  Information  Flow 

4.3.1  Inputs. 

a.  The  following  input  data  is  provided  to  the  wing  subsystem. 

(1)  Tasking  Data 

(2)  Aircraft  Status 

(3)  Aircrew  Status 

(4)  Fuels  Status 

(5)  Base  Status 

(6)  Munitions  Status 
*(7)  Equipment  Status 

*(8)  Personnel  Qualifications 
*(9)  Vehicles  Status 

*  For  later  implementation  blocks.  (Should  be  considered  for  working 
memory  and  data  storage  sizing/expansion  purposes.) 
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*  (10)  AGE  Status 

*  (11) TRAP  Status 


*  (12)  Maintenance  Support  Data 

*  (13)  Base  Support  Data 

b.  Input  Records.  Input  record  nomenclature,  source,  expected  volume,  frequency, 
priority,  degree  of  sensitivity  and  requirement  for  timeliness  are  described  in 
the  AFIRMS  Product  Descriptions  Document.  Interface  specifications 
corresponding  to  input  record  requirements  are  provided  in  Table  3-5  of  this 
subsystem  specification.  The  transaction  header  interface  specification 
detailed  in  Appendix  A  contains  information  to  discriminate  between  input 
records  and  input  data  element  transactions. 

c.  Input  Data  Elements.  Data  elements  for  each  input  record  type  are  described 
in  the  AFIRMS  Database  Specifications  and  the  Data  Requirements  Document. 
Interface  specifications  corresponding  to  input  data  element  requirements  are 
provided  in  Table  3-5  and  Appendix  B  of  this  subsystem  specification.  The 
transaction  header  interface  specification  detailed  in  Appendix  A  contains 
information  to  discriminate  between  input  records  and  input  data  element 
transactions. 


4.3.2  Outputs.  Operational  AFIRMS  outputs  include  reports  and  graphic  readiness 
measurement  displays  as  follows: 

a.  Output  Reports.  All  AFIRMS  output  reports  can  be  displayed  on  the  user's 
terminal  or  printed  as  hardcopy.  There  are  no  requirements  for  preprinted 
forms  for  generation  of  hardcopies. 

Output  reports  to  be  prepared  by  the  TFW  subsystem  provide  graphic  and/or 
tabular  product  screens  that  display  readiness  information  and  measurements  as 
well  as  scheduling  information.  Many  wing  output  products  assist  the  wing  user 
in  day-to-day  operations  and  provide  scheduling  capability  as  well  as  data  entry 
assistance. 

Table  4-1  provides  information  concerning  the  format,  complexity,  security 
classification,  and  estimated  daily  volume  and  frequency  of  AFIRMS  output 
reports.  For  response  times  of  these  AFIRMS  output  reports,  please  reference 
Section  2.2.3  of  this  subsystem  specification,  in  which  AFIRMS  query  response 
times  are  provided  for  varying  degrees  of  query  complexity. 

Table  4-2  details  the  primary  and  secondary  functional  area  users  of  AFIRMS 
output  reports.  In  addition,  these  outputs  are  fully  described  in  the  AFIRMS 
Product  Description  series.  (Additional  output  report  requirements  for  each 
Wing  will  be  reviewed  during  the  in-depth  analysis  that  precedes 
implementation  at  that  site.) 

b.  Output  Data  Elements.  Output  data  elements  are  described  in  the  AFIRMS 
Database  Specifications  and  the  interface  specifications  are  provided  in 
Appendix  B  of  this  subsystem  specification. 
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TABLE  4-1 


AFIRMS  OUTPUT  REPORTS 


Screen  Title 

Format 

Estimated 

Daily  Volume 
and  Frequency 

Complexity 

Security 

Classif- 

cation 

AGE  Availability  Status 

Tabular 

2  pg  @  12 

Simple 

Unclas 

AGE  Support  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Aircraft  Availability 

Graphic 

1  Pg  @  12.5 

Medium 

Conf 

Aircraft  Capability 

Graphic 

1  pg  @  12 

Medium 

Secret 

Aircraft  Status 

Tabular 

6  pg  @  200 

Medium 

Unclas 

Aircraft  Tasking 

Graphic 

1  pg  @  5 

Medium 

U-S* 

Aircrew  Availability 

Tabular 

1  pg  @  31 

Medium 

Conf 

Aircrew  Capability 

Graphic 

1  pg  @  12 

Complex 

Secret 

Aircrew  Generation 

Graphic 

1  Pg  @  31 

Medium 

Unclas 

Aircrew  Status 

Tabular 

2  pg  @  63 

Simple 

Unclas 

Airfield  Status 

Graphic 

1  pg  @  48 

Simple 

Unclas 

Base  Fuels  Capability 

Graphic 

1  Pg  @  6 

Medium 

U-S* 

Base  Status 

Tabular 

3  pg  @  48 

Simple 

Unclas 

Flying  Schedule  (Maintenance) 

Tabular 

6  pg  @  200 

Medium 

Unclas 

Flying  Schedule  (Operations) 

Tabular 

6  pg  @  100 

Medium 

Unclas 

Fuels  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Fuels  Status 

Tabular 

I  pg  @  60 

Simple 

Unclas 

Fuels  Status  Map 

Graphic 

1  pg  @  48 

Simple 

Unclas 

Individual  Resource  Capability 

Graphic 

1  pg  @  9 

Complex 

U-S* 

Integrated  Capability 

Graphic 

1  pg  @  6 

Complex 

U-S* 

Maintenance  Support  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Mass  Load  Generation  Schedule 

Tabular 

6  pg  @  120 

Simple 

Secret** 

Mission  Flow 

Graphic 

1  Pg  @  24 

Medium 

Secret 

Mission  Profile  Definition 

Tabular 

3  pg  @  3 

Simple 

U-S 

Munition  Flow 

Graphic 

1  Pg  @  24 

Medium 

Secret 

Munitions  A  6c  D  Availability 

Tabular 

2  pg  @  6 

Simple 

Unclas 

Munitions  Assembly  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Munitions  Availability  Forecast 

Graphic 

1  pg  @  9 

Simple 

Unclas 

Munitions  Capability 

Graphic 

1  Pg  @  6 

Medium 

Secret 

Munitions  Distribution  Capability 

Graphic 

1  pg  @  6 

Medium 

Secret 

Munitions  Load  Capability 

Graphic 

1  Pg  @  6 

Medium 

Secret 

Munitions  Load  Crew  Available 

Tabular 

6  pg  @  12 

Simple 

Unclas 

Note  1:  Depending  on  input  parameters,  some  times  will  increase/decrease  depending  on  the 
amount  of  data  retrieved.  For  example,  requesting  Munitions  Capability  for  60  days 
will  double  the  amount  of  data  and  time  over  a  30  day  parameter  input. 


Note  2:  One  page  @  1  denotes  that  the  average  screen  length  (volume)  is  one  page,  and  it  is 
used  once  daily. 

*  Some  classifications  have  a  range,  i.e.,  U-S,  meaning  Unclassified  through  Secret.  That  range 
normally  results  from  a  variable  tasking  classification  (e.g.,  some  tasks  are  Unclassified,  some 
are  Confidential,  some  are  Secret,  etc.).  Note  that  AFIRMS  does  not  initially  include  Top 
Secret  data  at  the  wing  level. 

**  SECRET  when  it  contains  actual  completion  times. 
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TABLE  4-1  (Continued) 


AFIRMS  OUTPUT  REPORTS 


Screen  Title 

Format 

Estimated 

Daily  Volume 
and  Frequency 

Complexity 

Security 

Classif- 

cation 

Munitions  Load  Crew  Flow 

Graphic 

1  pg  @  12 

Medium 

Unclas 

Munitions  Status 

Tabular 

3  pg  @  9 

Simple 

Secret 

OPlan/OPORD  Associations 

Tabular 

1  Pg  @  1 

Simple 

Unclas 

Order  Assignments 

Tabular 

1  pg  @  1 

Simple 

U-S* 

Process  Status 

Tabular 

1  pg  @  6 

Simple 

Unclas 

Refueling  Capability 

Graphic 

1  pg  @  12 

Medium 

Secret 

Refueling  Truck  Flow 

Graphic 

1  pg  @  12 

Medium 

Unclas 

Single  Aircraft  Summary 

Graphic 

1  pg  @  300 

Simple 

Unclas 

Supply  MICAP  Status 

Tabular 

1  pg  @  48 

Simple 

Unclas 

Task  Capability 

Graphic 

1  pg  @  12 

Medium 

Secret 

Tasked  Missions 

Graphic 

1  pg  @  8 

Simple 

Secret 

Tasked  Munitions 

Graphic 

1  Pg  @  23 

Simple 

Secret 

Tasking  Information 

Tabular 

2  pg  @  120 

Simple 

Secret 

Unit  Status  (Output) 

Tabular 

1  pg  @  65 

Medium 

U-S* 

War  Mobilization  Plan 

Tabular 

1  Pg  @  2 

Simple 

Secret 

Wing  Flying  Day 

Tabular 

1  pg  @  2 

Simple 

U-S* 

Wing  Operations  Rates 

Tabular 

1  Pg  @  2 

Simple 

U-S* 

Wing  Resource  Summary 

Tabular 

2  pg  @  2 

Medium 

U-S* 

Wing  Resupply  Schedule 

Tabular 

4  pg  @  2 

Simple 

U-S* 

ZH 

SiMcSd 


TABLE  4-2 


AFIRMS  OUTPUT  REPORTS  BY  FUNCTIONAL  AREA  USER 


Screen  Title  (Implemented) 

Primary  User(s) 

Supporting  User(s) 

Aircraft  Availability 

woe 

OPS,  AMU.  MOC 

Aircraft  Capability 

woe 

OPS,  MOC 

Aircraft  Status 

MOC.  WOC,  AMU 

OPS,  FUELS  CTL. 

MUN  CTL,  SUPPLY 

Aircraft  Tasking 

woe 

OPS 

Aircrew  Availability 

WOC 

OPS 

Aircrew  Capability 

WOC 

OPS 

Aircrew  Generation 

WOC 

OPS 

Aircrew  Status 

OPS 

WOC 

Base  Fuels  Capability 

FUELS  CTL,  WOC 

Base  Status  (I/O) 

WOC 

FUELS  CTL, MUNCTL , 

OPS,  SUPPLY,  MOC, AMU 

Base  Status  Report  (Rollup) 

WOC 

Flying  Schedule  (Ops  Seg  1) 

WOC,  OPS 

AMU 

Flying  Schedule  (Maint  Seg  2) 

MOC 

OPS,  FUELS  CTL.  AMU, 

MUN  CTL,  WOC 

Flying  Schedule  Header  File 

MOC,  WOC,  OPS 

Fuels  Capability 

WOC,  FUELS  CTL 

OPS 

Fuels  Status 

FUELS  CTL 

SUPPLY,  WOC 

Individual  Resource  Capability 

WOC 

OPS 

Integrated  Capability 

WOC 

OPS 

Order  Assignments 

WOC 

OPS 

Munitions  Status 

MUN  CTL 

WOC.  OPS 

Munitions  Availability  Forecast 

WOC 

MUN  CTL,  OPS 

Munitions  Capability 

MUN  CTL,  WOC 

OPS 

Mission  Profile  Definition 

WOC 

OPS 

OPLAN/OPORD  Associations 

WOC 

OPS 

Process  Status 

WOC 

OPS 

Resupply  Schedule 

WOC 

FUELS  CTL,  MUN  CTL 

Supple  MI  CAP  Status 

WOC,  MOC 

SUPPLY 

Tasked  Missions 

WOC 

OPS.  MOC 

Tasked  Munitions 

WOC,  MUN  CTL 

OPS,  MOC 

Tasking  Information 

WOC 

OPS,  MUN  CTL,  MOC 

Wing  Flying  Day 

WOC 

OPS 

Wing  Operations  Rates 

WOC 

MOC,  OPS 

Wing  Resource  Summary 

WOC 

FUELS  CTL,  MUN  CTL 

Base/Unit  Status  Rollup 

WOC 

Resource  Rollup 

WOC 

OPS 

Run  SGM 

WOC 

OPS 

Transmit  Base  Status 

WOC 

Transmit  Unit  Status 

WOC 

Transmit  Resource  Status 

WOC 

War  Mobilizaton  Plan 

WOC 

OPS 

TABLE  4-2 


AFIRMS  OUTPUT  REPORTS  BY  FUNCTIONAL  AREA  USER  (Continued) 


Screen  Title  (Unimplemented) 

Primary  User(s) 

Supporting  User(s) 

AGE  Availability 

MOC 

AMU.  MUN  CTL,  WOC 

AGE  Support  Capability 

Airfield  Status 

MOC,  WOC 

WOC 

OPS,  MOC 

Base  Status  Map 

Fuels  (POL)  Capability  (Bar) 

WOC.  OPS 

WOC,  FUELS  CTL 

OPS 

Fuels  Status  Map 

Maintenance  Support  Capability 

FUELS  CTL.  WOC 
MOC,  WOC,  AMU 

OPS 

Mass  Load  Generation  Schedule 

MOC,  WOC 

AMU,  OPS. FUELS  CTL 

Mission  Flow 

MOC,  WOC 

MUN  CTL 

OPS,  AMU.  FUELS 

Munition  Flow 

MUN  CTL,  WOC 

AMU,  MOC 

Munitions  A  8  D  Availability 

MUN  CTL 

MOC,  WOC 

Munitions  Assembly  Capability 

MUN  CTL 

WOC 

Munitions  Capability  (Bar) 

WOC 

AMU,  MUN  CTL 

Munitions  Distribution  Cap. 

MUN  CTL,  WOC 

MOC 

Munitions  Load  Crew  Flow 

AMU 

WOC,  MOC 

Munitions  Load  Crew  Status 

AMU 

WOC.  MOC 

Munitions  Loading  Capability 

WOC,  AMU 

MUN  CTL 

Refueling  Capability 

Refueling  Truck  Flow 

WOC.  FUELS  CTL 
FUELS  CTL 

WOC,  MOC 

Single  Aircraft  Summary 

MOC,  AMU 

WOC,  OPS,  FUELS 

Task  Capability 

WOC 

CTL,  MUN  CTL 

OPS,  MOC,  MUN  CTL, 

Unit  Status  (I/O) 

WOC 

FUELS  CTL,  AMU 

OPS 

ABBREVIATIONS /ACRONYMS 


AMU 

FUELS  CTL  - 
MOC 

MUN  CTL  - 
OPS 

WOC 


Aircraft  Maintenance  Unit 
Fuels  Control 

Maintenance  Operations  Center  or  Job  Control  Center 
Munitions  Control 

Wing  S  Squadron  Scheduling/Training,  Squadron  Operations, 
Wing  HQ 

Wing  Operations  Center  (LRC,  PRC,  SRC,  Sr.  Battlestaff, 
Mission  Director,  Frag  Shop) 
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4.3.3  Database  Description.  For  additional  AFIRMS  database  requirements,  refer  to  the 
AFIRMS  Wing  Database  Specification. 

a.  Database  Identification.  The  label  by  which  the  wing  level  database  is  uniquely 
identified  consists  of  the  wing  number,  wing  mission  type,  and  "DB"  as  a  suffix 
(e.g.,  52TFWDB).  The  wing  subsystem  maintains  databases  as  follows: 

(1)  Real:  This  database  contains  peacetime  and  crisis  tasking,  and  other 
day-to-day  operational  data. 

(2)  What  If:  This  physical  database  is  comprised  of  three  types  of  logical 
databases: 

(a)  Exercise  -  This  database  contains  data  which  provides  a  simulation 
of  an  actual  crisis. 

(b)  Ad-Hoc  What  If  -This  database  contains  data  which  provides  a 
simulation  of  a  hypothetical  crisis  or  situation. 

(c)  Historical  -  This  database  contains  data  which  provides  a  historical 
view  of  the  real,  exercise,  or  ad-hoc  what  if  databases. 

b.  Storage.  The  master  file(s)  containing  the  wing  level  database  are  stored 
on-line  on  mass-storage  disk  devices  and  off-line  on  magnetic  tape  and 
formatted  floppy /microfloppy  disk. 

c.  Database  Query  Capabilities.  The  design  of  the  AFIRMS  database  supports  the 
requirements  for  an  interactive  query  capability  accessing  current  and/or 
what-if  data  for  the  above-named  databases.  Historical  data  resides  primarily 
on  off-line  media  and  is  copied  to  on-line  media  on  an  "as-needed"  basis. 

(1)  Ad-Hoc  Querying.  Selected  users  may  execute  ad  hoc  queries  against  any 
on-line  databases  to  which  they  are  permitted  access.  Ad  hoc  querying  is 
constrained  by  AFIRMS  security  and  control  requirements.  This 
capability  is  limited  to  databases  located  at  the  functional  area  and  the 
central  location  within  a  site.  Controls  within  the  DBMS  and  security 
software  are  used  to  limit  access  to  both  the  functional  area  and  central 
database  on  a  user-by-user  basis. 

Ad  hoc  query  access  is  provided  by  the  AFIRMS  executive.  The  user  has 
the  ability  to  interactively  query  the  database  via  an  "English-like" 
AFIRMS  query  utility.  The  user  does  not  have  the  ability  to  update  any 
data  while  in  this  mode.  Ad  hoc  queries  are  limited  to  current  or  crisis 
mode  data  only.  When  data  is  requested,  if  it  is  not  present  in  the  local 
functional  area  database,  the  request  is  transmitted  to  the  central  node. 
The  request  is  then  processed  at  the  central  node  and  the  results  returned 
to  the  requesting  functional  area  for  display.  There  is  no  capability  for 
ad-hoc  querying  across  sites  within  AFIRMS. 


33511  4-9 


(2)  What-If  Capability.  A  what-if  capability  exists  in  AFIRMS  to  enable 
certain  users  to  input  hypothetical  tasking,  resource,  or  operations 
scenarios  to  better  predict  future  readiness  capability.  The  data  is  input 
into  the  local  database  through  a  highly  structured  AFIRMS  environment. 
The  what-if  capability  of  AFIRMS  directly  affects  the  amount  of  data 
redundancy  necessary  at  each  site  and,  accordingly,  the  amount  of 
physical  storage  capacity  necessary  to  handle  it.  What-if  data  storage 
needs  vary  according  to  the  level  in  the  command  structure  and  the 
functional  users'  what-if  exercise  needs. 

Database  Backup,  Restoration,  and  Archiving.  Backup  of  the  database  to 
off-line  media  occurs  on  a  daily,  weekly,  monthly,  and  yearly  basis;  each  backup 
is  maintained  for  a  different  length  of  time: 

(1)  Daily  Database  Backups.  Daily  backups  are  maintained  for  five  working 
days. 

(2)  Weekly  Database  Backups.  Weekly  backups  are  maintained  for  five  weeks. 

(3)  Monthly  Database  Backups.  Monthly  backups  are  maintained  for  12 
months. 

(4)  Yearly  Database  Backups.  Yearly  backups  are  maintained  for  five  years. 

Restoration  occurs  in  the  event  that  data  in  the  database  has  been  lost  or 
damaged.  Whenever  a  transaction  occurs  in  the  local  database,  it  will  be  logged 
to  a  journal  file  for  use  in  the  event  restoration  is  needed.  Restoration  consists 
of  reloading  the  latest  copy  of  the  database  from  off-line  media,  if  necessary, 
and  applying  the  journal  log  file  to  it. 

Archiving  of  data  to  tape  or  disk  is  accomplished  as  required  by  AFIRMS  users. 

Database  Size.  It  is  estimated  that  the  size  of  all  files  contained  in  each  wing 
database  is  a  total  of  approximately  1.6  megabytes. 

Database  Elements.  AFIRMS  TFW  database  elements  are  described  in  the 
AFIRMS  TFW  Database  Specification  and  Data  Requirements  Document. 


ss 


4.4  Program  Descriptions,  This  subsystem  specification  is  to  contain,  as  annexes,  C-level 
program  specifications  which  detail  specific  requirements  for  the  subsystem  functional 
products.  The  wing  subsystem  consists  of  the  following  programs  (in  addition  to  systems 
software): 

Screen/Process  Title 


AGE  Availability  Status 
AGE  Support  Capability 
Aircraft  Availability 
Aircraft  Capability 
Aircraft  Status 
Aircraft  Tasking 
Aircrew  Availability 
Aircrew  Capability 
Aircrew  Generation 
Aircrew  Status 
Airfield  Status 
Base  Fuels  Capability 
Base  Status 

Base/Unit  Status  Rollup 
Flying  Schedule  (Maintenance) 

Flying  Schedule  (Operations) 

Fuels  Capability 
Fuels  Status 
Fuels  Status  Map 

Individual  Resource  Capability  (Exercise) 
Integrated  Capability  (Exercise) 
Maintenance  Support  Capability 
Mass  Load  Generation  Schedule 
Mission  Flow 

Mission  Profile  Definition 
Munition  Flow 

Munitions  A  &  D  Availability 
Munitions  Assembly  Capability 
Munitions  Availability  Forecast 
Munitions  Capability 
Munitions  Distribution  Capability 
Munitions  Load  Capability 
Munitions  Load  Crew  Available 
Munitions  Load  Crew  Flow 
Munitions  Status 
OPLAN/OPORD  Associations 
Order  Assignments 
Process  Status 
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Screen/Process  Title 

Refueling  Capability 

Refueling  Truck  Flow 

Resource  Status  Rollup 

Run  Sortie  Generation  Model  (SGM) 

SGM  Associations 

Single  Aircraft  Summary 

Supply  MI  CAP  Status 

Task  Capability 

Tasked  Missions 

Tasked  Munitions 

Tasking  Information 

Transmit  Base  Status 

Transmit  Resource  Status 

Transmit  Unit  Status 

Unit  Status  (Output) 

War  Mobilizaton  Plan 
Wing  Flying  Day 
Wing  Operations  Rates 
Wing  Resource  Summary 
Wing  Resupply  Schedule 


For  detailed  descriptions  of  these  products,  refer  to  the  AFIRMS  Product 
Descriptions  Index  and  Document. 
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APPENDIX  A.  INTRASITE  TRANSACTION  HEADER 


Field  Name  Field  Description 


TRANS_ID  a.  Transaction  identifier. 

b.  Each  terminal  has  its  own  IDs. 

c.  The  legal  values  are  1— >65535.  After  65535,  it  reverts  back  to  1. 


TR  AN5_MSG_LEN  a.  Transaction  message  length. 

b.  The  length  is  the  sum  of  the  transaction  header  plus  data  length. 

c.  The  legal  values  are  85— >8192. 


REQ_REP_FLAG  a.  Request/Reply  flag. 

b.  User  interactive  display  software  always  sends  requests.  The  host 
always  sends  replies  in  response  to  the  request  as  long  as  the 
transaction  was  not  submitted  as  a  batch  job.  The  host 
occasionally  sends  unsolicited  requests  to  the  CGC  (i.e.,  update 
messages).  It  does  not  expect  a  reply. 

c.  The  legal  values  are  "Q"  for  request  and  "P"  for  reply. 


JOB  TYPE 


a.  Interactive/Batch/Network  flag. 

b.  All  jobs  must  run  interactively  if  they  expect  a  product  screen 
display.  Otherwise,  they  can  be  run  as  batch.  Note:  batch  jobs 
never  send  back  replies.  Their  status  can  be  monitored  through 
the  batch  monitor  screen. 

c.  The  legal  values  are  "I"  for  interactive,  "B"  for  batch,  and  "N"  for 
network. 


SRC  NODE  ID 


a.  Source  node  ID. 

b.  This  is  the  node  ID  of  the  requestor. 


SRC_TERMJD  a.  Source  terminal  ID. 

b.  This  is  the  terminal  ID  of  the  requestor. 

c.  The  legal  values  are  local  site  dependent.  Note:  the  value  1111  is 
reserved  for  host  generated  transactions  (i.e.,  unsolicated  update 
messages). 


SRCJJSER_N  A  ME  a.  Source  username. 

b.  This  is  the  username  of  the  requestor. 

c.  The  legal  values  are  site  dependent.  They  must  match  the 
username  used  for  logging  into  the  host. 


DST_NODE_ID  a.  Destination  node  ID. 

b.  This  field  is  filled  in  by  a  transaction  router.  It  is  the  same  as 
the  SRC_NODEJD  for  the  local  requests  that  require  a  reply.  In 
general,  it  is  always  the  node  ID  of  where  the  transaction  is 
destined.  It  differs  from  the  SRC_NODE_ID  only  for  network 
messages. 
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Field  Name 


DST  TERM  ID 


DST_USER_NAME 


EXP  DAT  TIM 


MOD_REQ_ID 


FUNC_REQ_ID 


Field  Description 

a.  Destination  terminal  ID. 

b.  This  field  is  filled  in  by  a  transaction  router.  It  is  the  same  as  the 
SRC_TERM_ID  for  the  requests  that  require  a  reply.  In  general,  it 
is  the  terminal  ID  of  where  the  transaction  is  destined.  It  differs 
only  for  network  messages. 

c.  The  legal  values  are  remote  site  dependent. 

a.  Destination  username. 

b.  This  field  is  filled  in  by  a  transaction  router.  It  is  the  same  as  the 
SRC_U5ER_NAME  for  the  requests  that  require  a  reply.  In 
general,  it  is  always  the  username  of  where  the  transaction  is 
destined. 

c.  The  legal  values  are  site  dependent.  They  must  match  the 
username  used  for  logging  into  the  host  for  local  transactions. 

For  network,  transactions,  the  username  "♦ROLLUP*"  is  reserved. 

a.  Transaction  expiration  date/time. 

b.  There  are  four  subfields: 

1.  Expiration  year 

b.  The  legal  values  are  0—  >99. 

2.  Expiration  day 

b.  The  legal  values  are  1 --  >366.  Note:  366  is  only  valid  for 
leap  years. 

3.  Expiration  hour 

b.  The  legal  values  are  0--  >23. 

4.  Expiration  minute 

b.  The  legal  values  are  0  --  >  59. 

a.  Module  request  ID. 

b.  This  field  is  looked  at  only  by  the  transaction  routing  mechanism 
to  determine  whether  the  transaction  is  destined  for  the  database 
server  or  somewhere  else. 

c.  The  legal  values  are  1  -->2.  Their  meanings  are  as  follows: 

1  =  forward  transaction  to  the  database  router 

2  =  AFIRM5  service  request 

a.  Function  request  ID. 

b.  This  field  is  looked  at  by  the  transaction  routing  mechanism  only 
when  MOD_REQ_ID  =  2.  It  signifies  what  AFIRMS  service  to 
perform.  Currently,  the  only  service  is  to  log  off  the  user. 

c.  The  legal  values  are  1  --  >10.  Their  meanings  (when  MOD_REQ 
ID=  1)  are  as  follows: 

1  =  organize  records  (send  transaction  H2) 

2  =  update  record 

3  =  insert  record 

4  =  delete  record 

5  =  logoff  Database 

6  =  edit  info  (send  transaction  //l) 

7  =  insert  continuation  record 

8  =  delete  continuation  record 

9  =  log  invalid  batch  job 
10  =  transmit  rollup  status 


Field  Name 


MSG  PRIO 


MSG  STAT 


MSG  SEG  CUR 


MSG  SEG  TOT 


$\ 


Field  Description 

a.  Message  priority. 

b.  This  field  is  used  by  the  process  controller  to  put  each  transaction 
it  receives  into  the  appropriate  priority  mailbox  (i.e.,  queue). 

(1)  The  transaction  router  uses  it  as  a  consistency  check  to  make 
sure  the  transaction  is  sent  to  the  right  mailbox,  and 

(2)  to  set  the  priority  of  the  Database  server  that  will  be 
processing  that  transaction,  and 

(3)  The  Database  server  uses  it  to  determine  to  which  priority 
mailbox  it  should  forward  replies. 

c.  The  legal  values  are  1  for  low  priority,  5  for  medium  priority,  and 
9  for  high  priority. 

a.  Message  status. 

b.  This  field  is  used  for  returning  the  status  of  a  user's  request. 

c.  The  legal  values  are  any  32-bit  number.  Note:  MSG  STAT  must 
be  initially  set  to  0  in  the  original  request. 

a.  Message  number  current. 

b.  This  field  is  the  current  message  segment  number.  It  is  always  1 
unless  there  is  a  multi-part  transaction  (i.e.,  one  that  must  split 
because  it  is  too  large  for  a  single  buffer). 

c.  The  legal  values  are  1  —  >235. 

a.  Message  number  total. 

b.  The  legal  values  are  1  — >2 55. 
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APPENDIX  B 


B.l  Data  Interface  Specification  (GENEDIT) 


Date:  31-May-1985 


Current 

Olcest 

Latest 

As-of- 

Screen 

Time-of- 

screen 

screen 

status 

Classification 

day  DTG 

value  DTG 

value  DTG 

DTG  flag 

As-of-status 

It  of 

DTG 

subtitles 

Repeats^#  of  subtitles)times 


Subtitle 


records 


■Repeats  < 'It  of  records)  times 


It  of  continuation 
lines 


Repeats  for  all  fields  in  a  recoro 


■  Repeats  <//  of  continuation  lines)  times 
—  Repeats  for  all  fields  in  a  continuation  line 


Field  Name 

Screen  classification 

Current  time-of-day  DTG 

Oldest  screen  value  DTG 

Latest  screen  value  DTG 

As-of-status  DTG  flag 

As-of-status  DTG 

it  of  subtitles 

Subtitle 

tt  of  records 

It  of  continuation  lines 

Length  of  field 

Field 


Field  Length 


Note:  (1)  Each  field  whose  length  is  represents  a  variable  length  field.  The  fields 
are  preceded  with  a  2-byte  length  descriptor. 

(2)  The  number  of  fields  in  a  record  or  a  continuation  line  is  screen  specific. 
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B.2  Data  Interface  Specification  (CAPABILITY)  Date:  3 1-May- 1985 

The  AREA-C  buffer  layout  for  CAPABILITY  SCREENS  is  as  follows: 


Current 

Oldest  Latest 

As-of- 

Screen 

Time-of- 

screen  screen 

status 

Classification 

day  DTG 

value  DTG 

value  DTG 

DTG  flag 

—  Repeats <#  of  subtitles)  times 


As-of-status 

//  of 

DTG 

subtitles 

it  of 

it  of 

taskings 

days 

Subtitle 


-  Repeats <// of  taskings)  times 

i—  Repeats  <7/  of  days)- times 


Tasked 
item  name 


T  asked 
amount 


Repeats  <Jt  of  capable  lines  per  tasking) 

I — Repeats</>  of  days) times 


//  of 
capable 
lines  per 
tasking 


Capable 

item 

name 


Capable 

amount 


Field  Name  Field  Length 

Screen  classification  1 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

As-of-status  DTG  flag  1 

As-of-status  DTG  ? 

//  of  subtitles  2 

Subtitle  ? 

//  of  taskings  3 

it  of  days  3 

tasked  item  name  ? 

tasked  amount  ? 

it  of  capable  lines  per  tasking  ? 

capable  item  name  ? 

capable  amount  ? 

:  Each  field  whose  length  is  represents  a  variable  length  field.  The  fields 

are  preceded  with  a  2-byte  length  descriptor. 


B.3  Data  Interface  Specification  (MAP)  Date:  3 1-May- 1985 

The  AREA-C  buffer  layout  for  MAP  SCREENS  is  as  follows: 


Current 

Oldest 

Latest 

As-of- 

Screen 

Time-of- 

screen 

screen 

status 

Classification 

day  DTG 

value  DTG 

value  DTG 

DTG  flag 

As-of-status 

DTG 


#  of 

subtitles 


Repeats<//  of  subtitlesptimes 


Subtitle 


■Repeats<#  of  records>times 

—  Repeats  for  the  It  of  fields  in  this  screen's  record. 


It  of 
records 


Field  Name _  Field  Length 

Screen  classification  1 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

As-of-status  DTG  flag  1 

As-of-status  DTG  ? 

It  of  subtitles  2 

Length  of  subtitles  2 

Subtitle  ? 

It  of  records  3 

Length  of  field  2 

Field  ? 

e:  (1)  Each  field  whose  length  is  represents  a  variable  length  field.  The  fields 
are  preceded  with  a  2-byte  length  descriptor. 

(2)  The  number  of  fields  in  a  record  is  screen  specific. 
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B.4  Data  Interface  Specification  (FORECASTS)  Date:  31-May-1985 

The  AREA-C  buffer  layout  for  AVAILABILITY  FORECAST  SCREENS  is  as  follows: 


Historical 

If  of 

If  of 

If  of 

Expenditure 

average 

historical 

Critical 

forecast 

offbase 

rate 

flag 

days  avg. 

level 

days 

locations 

_ _ Repeats  <#  of  historical  days  plot)>  times 


//  of 

Amount 

historical 

on  hand 

days  plot 

(day  IfX) 

//  of 

If  of 

days  to 

days 

critical 

remaining 

Field  Name 


Field  Length 


Screen  classification  1 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

As-of-status  DTG  flag  I 

As-of-status  DTG  ? 

It  of  subtitles  2 

Subtitle  ? 

Expenditure  rate  ? 

Historical  average  flag  l 

If  of  historical  days  avg.  3 

Critical  level  ? 

If  of  forecast  days  3 

//  of  offbase  locations  1 

If  of  historical  days  plot  3 

Amount  on-hand  (day  // 1  -n)  ? 

//  of  days  to  critical  3 

If  of  days  remaining  3 


Note:  Each  field  whose  length  is  represents  a  variable  lengti  field.  These  fields  are 
preceded  by  a  2-byte  length  descriptor  field. 


B.5  Data  Interface  Specification  (BAR  CHART  WITH  LINES) 


Date:  31 -May- 1985 


The  AREA-C  buffer  layout  for  BAR  CHART  WITH  LINE  SCREENS  is  as  follows: 


Current 

Oldest 

Latest 

Screen 

Time-of- 

screen 

screen 

Task  ID 

classification 

day  DTG 

value  DTG 

value  DTG 

DTF  flag 

r—  Repeat s<//  of  subtitles>times 


Task-ID 

//  of 

DTG 

subtitles 

Subtitle 


r—  Repeats  <//  of  bars>  times 


//  of 
bars 


Bottom 

Top 

bar 

bar 

height 

height 

r—  Repeats <//  of  bars>times 


//of 

Line 

bars 

height 

Field  Name _  Field  Length 


Screen  classification  l 

Current  time-of-day  DTG  16 

Oldest  screen  value  DTG  16 

Latest  screen  value  DTG  16 

Task-ID  DTG  flag  1 

Task-ID  DTG  ? 

//  of  subtitles  2 

Subtitle  ? 

//  of  bars  3 

Bottom  bar  height  ? 

Top  bar  height  ? 

Line  height  ? 


Note:  Each  field  whose  length  is  represents  a  variable  length  field.  Only  these 
fields  shall  be  preceded  by  a  2-byte  length  descriptor  field. 
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B-5 


Date:  31-May-19&4 


B.6  Data  Interface  Specification  (BAR  CHART) 

The  AREA-C  buffer  layout  for  BAR  CHART  SCREENS  is  as  follows: 


Repeats  (//  of  bars)  times 


Fr 
bar 
value 


Rear 

Fr 

bar 

ba 

value 

co 

■ 


Rear 

bar 

color 


Field  Name  Field  Length 

//  of  bars  3 

Label  for  bar  ? 

Front  bar  value  ? 

Rear  bar  value  ? 

Front  bar  color  3 

Rear  bar  color  3 

Note:  Each  field  whose  length  is  represents  a  variable  length  field.  These  fields  are 
preceded  by  a  2-byte  length  descriptor  field. 
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